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APPELLANTS’ APPEAL BRIEF 

This is Appellant’s Brief on Appeal pursuant to 35 U.S.C. § 134(a). The following 
sections of this Brief are the items set forth in 37 C.F.R. § 41.37(c). 

Real Party in Interest £37 C.F.R. § 41.37(c) (U fiV) 

The Go Daddy Group, Inc., a corporation under the laws of Arizona and assignee of the 
inventors Robert R. Parsons, Joshua T. Coffman and Barbara J. Rechterman, is the real party in 
interest. 

Related Appeals and Interferences (37 C.F.R. 41 .37(c) ('ll tiiY) 

There are no related appeals or interferences. 

Status of Claims (37 C.F.R. § 41.37(c) (U (niY) 

Claims 1 - 26 - rejected. 

Claims 1 - 26 are all of the claims present in this application. Each of claims 1 - 26 is 
under final rejection. The claims on appeal are appended at Appendix A. 
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Status of Amendments (37 C.F.R. § 41.37(c) £1) (ivT) 

There has been no amendment of the application subsequent to the final rejection dated 
March 20, 2008. 

Summary of Claimed Subject Matter (37 C.F.R. § 41 .37(c) (1) (vY) 

Without limiting the interpretation of claims in appellants’ application, which claims 
stand on their own, all claims relate to “proxy email” installations, methods or programming 
where a proxy entity receives email for customers, at customer proxy email addresses, then 
decides which, if any, email message to send to a customer in an email to the customer’s actual 
email address based on the customer’s previously expressed preferences. 

The independent claims involved in this appeal are 1,2,6 and 1 1 . Again, without 
limiting the interpretation of the claims to the specific elements of any exemplary embodiment 
described in the specification, the following explains the claims' subject matter with reference to 
the specification and drawing figures. References in parentheses are to the drawing figure, page 
and line number of the appellants’ application as filed on February 28, 2005. 

Independent Claim 1 

The independent claim 1 is directed to a "proxy email computer installation" (block 60 in 
Fig. 3 or Fig. 7). The installation includes a database in computer memory (as indicated at 194 
in Fig. 8b) that associates a customer's identification (which can include the customer's personal 
contact information shown at 194 in Fig. 8b and as described, for example, at page 10, lines 4 - 
20). Also included in the proxy email computer installation is "an email server having an ability 
to receive a first email message at the customer's email address" (Fig. 9, block 136, page 10, 
lines 9 - 12). 

The proxy email computer installation of claim 1 has "computer executable code on a 
computer usable medium or media" (represented by the flow chart of Fig. 9, page 10, line 10). 
This code includes "(i) first programming to retrieve a customer’s actual email address from the 
database upon receipt of the first email message to the customer's proxy email address" (block 
138 of Fig. 9, page 10, lines 10 - 13). The code also includes "(ii) second programming to 
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forward a second email message to the customer's actual email address, wherein the second 
email message is formed from the first email message" (Fig. 9, block 148 and page 10, lines 32 - 
34). 



The proxy email computer installation of claim 1 further includes "a connection to a 
communication link forwarding the second email message to the customer's actual email 
addresses" (the communication line 150 of Fig. 9, page 11, lines 1 and 2). 

Claims dependent from Claim 1 

Claims 15 - 18 are dependent claims depending from claim 1 directly or through mesne 
dependencies. 

Claim 15 provides that the email server of claim 1 "is set up to receive all incoming 
proxy emails to a common catch-all account" (page 10, lines 13 and 14). Claim 15 also provides 
that "the email computer installation further comprises an email address management system" 
(Fig. 7, block 60) "that periodically checks for new emails for any customer" (page 10, lines 1 5 - 
17). 



Claim 16, dependent from claim 15, provides that "the first programming to retrieve a 
customer's actual email address includes programming to check email addresses of all addressed 
and copied parties for a proxy email address being served by the proxy email server whenever a 
new email is found by the email address management system" (page 10, lines 21 - 23). 

Claim 17 is dependent from claim 16 and provides "the second programming comprises 
programming to copy the content of the first email message into the second email message, the 
second email message comprising an email message from the proxy computer installation to the 
customer at the customer's actual email address" (page 10, lines 32 - 34). 

Claim 18 depends from claim 17 and further provides "programming in computer 
executable code on a computer usable medium or media to effect deletion of an email once 
addresses of all addressed and copied parties have been checked for proxy email addresses of 
customers and any content has been copied to an email to the actual email addresses of any 
customers whose proxy email addresses have been found" (page 1 1 , lines 2 and 3). 
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Independent Claim 2 

Independent method claim 2 claims a method of proxy email address management (Fig. 
9, specification p. 10, line 9 - p. 11 line 12). that includes (a) "associating a proxy email address 
with a customer having a customer's actual email address" (shown at 194, Fig. 8b). The method 
of claim 2 further includes (b) "receiving an email intended for the customer at the proxy email 
address" (indicated at 136 in the Fig. 9 flow chart, page 10, lines 9 and 10). Additionally, the 
claim 2 method includes (c) "forwarding the email to the customer's actual email address" (Fig. 
9, block sl48 and 150, page 10, line 32 - page 11, line 3). 

Claims Dependent from Claim 2 

Claims 3 - 5, 19 - 26 are dependent claims. These depend from claim 2 or from one or 
more claims dependent from claim 2. 

Claim 3 is dependent from claim 2. This claim provides that the method of claim 2 
further comprises (d) "recording the proxy email address in a database in association with the 
customer's actual email address" (indicated at 194 in Fig. 8b, page 9, lines 23 - 27), and (e) 
"looking up the customer's actual email address upon receiving the email at the proxy email 
address" (block 138 of Fig. 9, page 10, lines 23 - 24). 

Claim 4 is dependent from claim 3. It adds the step of "causing a Web page to be 
displayed that bears the proxy email address" (The “WHOIS,” Fig. 3, block 27, item 23, Fig. 10, 
page 7, lines 22 - 29, Fig. 8c, items 202 and 23, page 9, lines 27 - 31). 

Claim 5 is dependent from claim 3. Claim 5 further provides the steps of "receiving a 
second email from the customer" (Fig. 7, items 20, 132 and 60, page 9, lines 8-12) and 
"forwarding the second email to a third party identified by the customer" (Fig. 7, items 60, 130 
and 29, page 9, lines 8 - 12). 

Dependent claim 19 is dependent from independent claim 2. This claim provides 
"receiving all incoming proxy emails to a common catch-all account" (page 10, lines 13 and 14) 
and "periodically checking for new emails for any customer" (page 10, lines 15 - 17). 
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Dependent claim 20 depends from claim 19. Claim 20 provides that "periodically 
checking for new emails for any customer comprises checking addresses of all addressed and 
copied parties for a proxy email address associated with any customer whenever a new email is 
found" (Page 10, lines 32 - 34). 

Dependent claim 21 depends from claim 20. It calls for "forwarding the email to the 
customer's actual email address comprises copying the content of the email into a second email 
to the customer's actual email address" (page 10, lines 32 - 34). 

Dependent claim 22 is dependent from claim 21 and provides "deleting an email once 
addresses of all addressed and copied parties have been checked for proxy email addresses of 
customers and the email has been copied to the actual email addresses of any customers whose 
proxy email addresses have been found" (page 1 1, lines 2 and 3). 

Claim 23 is dependent from independent claim 2 and adds the step of "receiving a non- 
email message sent to the customer at a location based on publicly available proxy contact 
information" (page 1 1 , lines 6 - 9). 

Claim 24, dependent from claim 23, further provides that "receiving non-email messages 
comprises receiving a message by ground carrier service" (page 11, lines 6 - 9). 

Claim 25 is dependent from claim 23. This claim provides "alerting the customer to the 
receipt of the non-email message" (Fig. 13, page 11, lines 10 and 1 1). It also provides "affording 
the customer the opportunity to request receipt of the non-email message" (Fig. 13, item 214, 
page 11, lines 1 1 and 12) and "forwarding the non-email message to the customer if the customer 
requests receipt of the non-email message" (page 11, lines 4 and 5). 

Claim 26 is dependent from dependent claim 4. It provides that step (f) of claim 4 
comprises "saving the proxy email address into whois data for a domain name" (Fig. 7, items 24, 
27 and 60, page 9, lines 32 - 34). 

Independent Claim 6 

Independent claim 6 calls for a proxy email computer installation including "a database in 
computer memory storing customer information in association with a proxy email address, 
1933741 5 
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wherein the customer information includes a customer's actual email address" (indicated at 1 94 
in Fig. 8b, page 9, lines 23 - 27). The computer installation of claim 6 has "an email server to 
receive an email intended for a customer at the proxy email address" (Fig. 9, block 136, page 10, 
lines 9 - 12). The claim 6 installation includes "computer executable code on a computer-usable 
medium or media providing" (represented by the Fig. 9 flow chart, page 10, line 10) providing 
"first programming to detect the email received at the email server intended for the customer" 
(block 138 of Fig. 9, page 10, lines 12 - 13). The code also provides "second programming for 
retrieving the customer's actual email address from the database upon receipt of the email" 

(block 138 of Fig. 9, page 10, lines 23 - 24) and "third programming to forward the email to the 
customer's actual email address" (Fig. 7, items 20, 60 and 132, page 9, lines 2 - 4). The 
installation of claim 6 provides, as well, "a connection to a communication link for forwarding 
the email to the.customer's actual email address" (Fig. 7, link 132, page 9, lines 2 - 4). 

Claims Dependent from Claim 6 

Dependent claim 7 adds to the proxy email computer installation of claim 6 "a filtering 
software in computer-executable code on a computer-usable medium or media for preventing an 
objectionable email being forwarded to the customer" (Fig. 9, blocks 144, 146, page 10, lines 27 
-32). 



Claim 8 depends from claim 7 and provides "in said database, an indication of customer's 
choice or choices for an email filtering" (page 9, lines 5 - 7). 

Claim 9, dependent from claim 8, provides for customer choices of: 

(i) no filtering; 

(ii) blocking all emails addressed to the proxy email address associated with 
the customer's information; and 

(iii) blocking objectionable emails addressed to the proxy email address 
associated with the customer's information 

(Fig. 9, decision blocks 140 and 144, page 10, lines 24 - 30). 

Claim 10 is dependent from claim 9 and provides that "the blocked objectionable email is 
selected from the group consisting of SPAM, bulk email, advertising, pornography and code to 
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interfere with a computer's workings" (Fig. 9, decision blocks 140 and 144, page 10, lines 24 - 
30). 

Independent Claim 1 1 

Claim 1 1 is independent. The claim is drawn to a computer program (the Fig. 9 flow 
chart) for proxy email address management (Fig. 7, block 60) that comprises computer- 
executable code on a computer usable medium or media (a) "first programming establishing a 
database for storing customer information in association with a proxy email address, wherein the 
customer information includes a customer’s actual email address" (indicated at 194 in Fig. 8b, 
page 9, lines 23 - 27). The claim 1 1 program further includes (b) "second programming to 
identify a first email intended for a customer addressed to the proxy email address" (block 138 
of Fig. 9, page 10, lines 12 - 13). The claim also provides (c) "third programming to retrieve the 
customer's actual email address" (block 138 of Fig. 9, page 10, lines 23 - 24), (d) "fourth 
programming to copy content of the first email to a second email" (page 10, lines 32 - 34), and 
(e) "fifth programming operative to send the second email to the customer's actual email address" 
(Fig. 9, item 150 and page 10, line 32 - page 1 1, line 2). 

Claims Dependent from Claim 1 1 

Dependent claim 12 is dependent from independent claim 1 1 and adds to the computer 
program of claim 1 1 "sixth programming to identify a third email from the customer" (Fig. 7, 
items 20, 132 and 60, page 9, lines 8-12) and "seventh programming for copying content of the 
third to a fourth email for the customer's intended recipient" (Fig. 7, items 60, 130 and 29, page 
9, lines 8-12). 

Dependent claim 13 depends from independent claim 1 1 and further comprises "sixth 
programming for filtering out objectionable emails" (Fig. 9, blocks 144, 146, page 10, lines 27 - 
32). 

Dependent claim 14 depends from claim 13 and further provides "seventh programming 
for receiving a customer's choice or choices of filtering and for storing the choice or choices in 
the database" (Fig. 12, page 9, line 5-7) and "eighth programming to recognize the customer's 
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choice or choices and filter or not filter emails to the customer based on the customer's choice or 
choices" (Fig. 9, blocks 144, 146, page 10 lines 24 - 32). 

Grounds of Rejection to be Reviewed on Appeal (37 C.F.R, $ 41.37(c) (1) (viY) 

All of claims 1 - 26 stand rejected under 35 U.S.C. § 102(e) as anticipated by a published 
continuation-in-part U.S. patent application No. 2003/0 19 1969 A 1 of Katsikas ("the Katsikas '969 
published CIP” or “CIP application"). That application is attached for the Board's convenience 
at Appendix D. 

Argument 137 C.F.R. $ 41.37(c) £j) (vim 

First, because those portions of the relied-upon Katsikas '969 published CIP that are 
entitled to a "prior art date" early enough to qualify as prior art as to the present application do 
not disclose the proxy email provisions of the rejected claims of this application, the rejection of 
all claims as anticipated by the '969 published CIP is in error and cannot stand. Second, cited 
portions of the predecessor applications from which the Katsikas ‘969 published CIP claims 
priority do not supply the additional content needed to reject the claims as “anticipated.” Third, 
even taken in their totality, irrespective of the filing date to which they are entitled or whether the 
content can be considered as part of the published ‘969 CIP, the Katsikas published CIP and its 
predecessor applications do not have disclosure capable of anticipating the invention as claimed. 

Katsikas Briefly 

The Katsikas published CIP application, parent application and provisional application 
relate to computer software used by a “subscriber” for eliminating unwanted "spam" email. The 
software features of the Katsikas provisional, parent and CIP applications changed with each 
filing. For each application, however, incoming email is compared to an "authorized sender list" 
or "ASL" to determine whether to block incoming email from reaching its intended recipient. 
Content that the examiner quotes from the provisional application in support of the final rejection 
is not present in the published CIP application on which the rejection is based. The published 
CIP application introduces for the first time a processor called variously a "SkProxy Processor" 
202 (In Fig. 2), an "email proxy preprocessor" (paragraph 0027) or a "skproxy preprocessor" 
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(paragraph 0037). Prior to the filing of the CIP application, nothing described as a “proxy” had 
been disclosed. 

The Relevant Applications and Their Effective File Dates 

Filed March 31, 2003, the Katsikas '969 published CIP application is entitled to priority 
from parent application Serial No. 09/648,894 filed August 25, 2001 (the "parent '894 
application") only for subject matter common to the parent and this continuation-in-part 
application. Transco Products Inc. v. Performance Contracting, Inc., 38 F. 3d 551, 556-57, 32 
U.S.P.Q. 2d (BNA) 1077, 1080 (Fed. Cir. 1994). The parent '894 application of Katsikas claims 
priority from a provisional application Serial No. 60/180,937 (the '937 provisional) filed 
February 8, 2000. Subject matter from the Katsikas '969 published CIP application relied upon 
in and essential to the rejection under 35 U.S.C. § 102(e) was introduced upon the March 31, 
2003 filing of that continuation-in-part application. As to that content, the relied upon '969 
published CIP is not prior art as to this application on appeal which has a priority date of August 
30, 2002. Appellants’ August 30, 2002 priority date is the filing date of an international (PCT) 
application serial No. PCT/US02/27956. This application on appeal is a divisional of the 
international application’s U.S. National Stage Serial No. 10/624,883 (now U.S. patent No. 
7,130,878). Appellants’ priority and the lineage of this application is in the record at the 
application’s Cross Reference to Related Applications as amended February 28, 2005. 

The Basis of the Examiner's Rejection under 35 U.S.C. $ 102(e) is in Error 

In a December 13, 2007 response to an Official Action applicants pointed out that the 
portions of the Katsikas '969 CIP relied upon in the rejection of the claims were not entitled to a 
date sufficiently early to qualify as prior art. In the subsequent, final Official Action of March 
20, 2008 the rejection was nevertheless maintained. There it was stated, incorrectly, that the 
subject matter not explicitly included in the prior PCT provisions and parent applications was 
present in software (called "SpamKapu software") that was said by the examiner to have been 
included in the provisional application. For the Board's convenience, a copy of the '937 
provisional and '894 parent applications are attached at Appendices E and F. The SpamKapu 
software is not itself included in the Katsikas '937 provisional, but rather, aspects of that 
software, as of the time of filing, are described and flow-charted. 
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"Proxy email" installations, methods and programming are the subject of each of the 
independent claims 1, 2, 6 and 1 1 in this application. The installation, method and programming 
for proxy email of all claims at issue relate to the operation of an entity established to receive 
email addressed to a "customer" at an email address other than the customer's actual email 
address, in order to keep from the customer such email as the customer does not want to receive. 

The Katsikas '969 published CIP application, parent '894 application, and '937 
provisional relate to gate keeping software that a subscriber can use to let pass to the subscriber 
email from a sender whose identification appears on an "approved sender list" ("ASL"). In 
support of the alleged anticipation by the Katsikas published CIP in the final rejection the 
examiner states, at page 3 of the final Official Action: 

As per claims 1 , 2, 6 and 1 1 , Katsikas teaches a proxy email computer installation (par 
0105, 0107, 01 09-0 110) including: 

A database (fig 2, elements 204, 2 1 6) in computer memory associating a 
customer's identification, a customer actual email and a customer’s proxy email address 
(fig 2 and 10-11; par 0092); an email server (102) ...; a computer executable code on a 
computer usable medium or media providing: first programming to retrieve a customer's 
actual email address ... (par 0092-0094); second programming to forward (redirector 
203) a second email message to the customer's actual email address; and a connection to 
a communication link forwarding (106) the second email message to the customer's 
actual email addresses (fig 1-2 and 10-1 1; par 0043-0045; 0092-0094 and 0100). 

As for the assertion "Katsikas teaches a proxy email computer installation," the 
paragraphs 0105, 0107, 0109 - 01 10 that the examiner cites in support are not available as prior 
art as to the claims of this application. Paragraphs 0105, 0107, 0109, - 01 10 were new matter 
when the Katsikas CIP application was filed on March 31, 2003. The Katsikas ‘969 published 
CIP application attached here as Appendix D has indicated the content introduced only as of the 
continuation-in-part. March 3 1 , 2003 filing date. 

The Katsikas ‘969 published CIP on which the examiner bases the rejection does refer to, 
for example, “a proxy preprocessor 202,” “proxy addresses,” and a “Skproxy Instantiation 
Table” at pars. 27, 37, 91 — 102 and 100 — 102 and in Figs. 2, 10 and 12, but only in the “new 
matter” parts of the CIP first introduced in the application on the March 31, 2003 CIP filing date. 

Concerning the individual Katsikas elements of the above-quoted statement in support of 
the rejection, elements 204 and 216 of Fig. 2 of the Katsikas ‘969 published CIP were present in 
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the earlier filed Katsikas applications. However, elements 204 and 216 of Fig. 2, the "Spam 
Processor," and the “Other Data Sources,” do not related to a “database” to associate a 
customer's identification, actual email address and proxy email address as the examiner asserts. 
The function of Katsikas’ “spam processor” is at paragraph 37 of the ‘969 published CIP. 

The Redirector 203 sends a request for validation for the email from the Spam Processor 
204 which maintains the Spam Processing Database (SPDB) 205, including the 
Authorized Senders Rules List (ASL) 206. The SPDB Database and ASL Rules List are 
the heart of SPAMKAPU, as they contain the processing rules and lists of persons 
authorized to send email to the respective SUBSCRIBERS of the system. The Spam 
Processor 204 sends a response, either that the sender’s address on the email is not 
authorized on the ASL List, i.e., is a SPAMMER, or is authorized on the ASL rules list, 
i.e., is a FRIEND, or is not present at all on the ASL rules list, i.e. is a UNKNOWN. 

In other words the “Spam processor 204” is involved in communications from and to email 
senders who are possible spammers, not the subscribers (or “customers” as the claims put it) that 
are to be protected from spam. 

Similarly the element 216 of the Katsikas '969 published CIP that the examiner cites is 
described as containing data such as "header data from sent email and data from other data 
sources," (paragraph 0042). It was never, as is contended in the examiner's rejection, said to be 
"associating a customer's identification, a customer actual email, and a customer's proxy email 
addresses." The examiner's mistaken characterization of the Katsikas '969 published CIP's 
content in this respect is a central flaw in the anticipation rejection of every claim in this 
application because each independent claim in the application includes claim content associating 
the proxy and “actual” email addresses of a customer. 

The further application figures, Figs. "10-1 1," and the paragraph, "par 0092," that the 
examiner cites as to the “database” were new matter in the Katsikas '969 published CIP upon 
filing. They are not entitled to the filing date of either of the earlier Katsikas '894 parent or '937 
provisional application. 

In the above-quoted segment of the examiner’s rejection the examiner correctly cites 
element 102 of Katsikas as an "email server." This does not alter the failure of the Katsikas 
published CIP to anticipate the claims however. 
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Paragraphs 0092 - 0094 are cited in the foregoing quote from the final rejection for 
teaching the claimed "code ... providing ... first programming to retrieve a customer's actual 
email address." But paragraphs 0092 to 0094 are new matter as to the Katsikas '969 CIP and 
unavailable to support the rejection. (That the cited paragraphs do not actually provide what is 
stated in the final Official Action is treated below.) 

"Figs. 1 and 2 and 10, 11" and paragraphs 0043 to 0045 and 0092 to 0094 and 0100 the 
examiner cites for a communication link (identified as 106) for sending a second email "to the 
customer's actual email address." Figs. 1 and 2 of the Katsikas ‘969 published CIP show nothing 
of the kind. Item 106 is a generalized indication of the internet in Figs. 1 and 2. In Figs, la and 
lb email is shown received from the internet 106. This is email for a subscriber or customer 
('969 published CIP paragraph 0028 as to Fig. 2a, paragraph 0030 as to Fig. lb). Mail is not 
shown being sent through the internet 1 06 to the subscriber or customer as contended by the 
examiner. Rather, the email shown being sent via the "customer email client 101," which is the 
internet service provider such as Outlook or Netscape, is being sent from, not to, the subscriber 
or customer (again, paragraphs 0028, 0030 of the '969 published CIP application). The Katsikas 
'969 CIP Fig. 2 shows subscriber or customer email client 101 sending the customer's email 
message via a SMTP send manager 214 and standard "SMTP Send process." There is no 
suggestion in any of this of sending a second email message to a customer's actual email address 
as alleged in the paragraph quoted above. 

Given the foregoing then, the rejection entirely misstates the operations described in the 
published CIP and by virtue of that the final rejection in this application is in error and should be 
overturned even before considering what if anything further from the preceding ‘894 parent and 
‘937 provisional can be relied upon to supplement the teaching of the ‘969 published CIP. 
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The Rejection's Flawed Grounds for Reiving on Non-Prior Art Subject Matter in the 
Continuation-in-Part 



To justify persisting in the original rejection of claims in this application as anticipated by 
the Katsikas '969 published CIP application, the examiner contends that the '937 provisional 
patent application from which the Katsikas '969 published CIP application claims priority 
contains subject matter that supports the new matter that was introduced into or teaches what is 
lacking from the relied upon CIP. This basis for maintaining the mistaken rejection over the 
published CIP errs in three ways. 

First, the ‘937 provisional application content that the examiner cites to justify the 
rejection based on of the Katsikas ‘969 published CIP was dropped from the Katsikas line of 
applications and never became a part of the published application entitled to the ‘937 provisional 
application filing date. Second, that part of the earlier ‘937 provisional application that the 
examiner cites does not actually teach, support, expand on or explain the relied-upon new matter 
provisions or needed or missing features of the '969 continuation-in-part published application 
and so cannot support the rejection. Third, and most important, even if the content of the 
provisional application referred to by the examiner were considered to be a part of the '969 
Katsikas published CIP application, the application still would not meet the terms of the rejected 
claims. 

At page 4 of the final Official Action, the examiner states in the Response to Arguments 
in the final rejection: 

Applicants argued that Katsikas does not qualify as prior art for this application 
because the provisional application "937" and the parent application "894" lack pertinent 
details such as proxy email as recited by Katsikas "969." 

Examiner submits that although Katsikas does not elaborate on email proxy, this 
feature is included in SpamKapu software (see pages 7-8 of "937"; fig. 1-8). 

The examiner then quotes from the '937 provisional application: 

As a server-side software package or online service SUBSCRIBERS are added 
to SpamKapu system. Each SUBSCRIBER is provided with a PSM, ASM, and UMM 
and an SKE. 
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The SUBSCRIBER changes appropriate setting on their email software to 
accomplish the following: 

Use current interact standards (currently POP3 or IMAP4) to retrieve mail from 
both the PSM and ASM. 

Redirect email sent to their current email address to their SKE instead OR set the 
email reply-to address to their SKE. Use the SMTP manager to handle the sending of all 
email. Any email sent to the SKE is processed by the redirector as described above. Any 
email sent by the SUBSCRIBER through the ASL manager (via the SMTP manager) 
and processed as described above. 

The user can retrieve email from the ASM at any time using Internet standards 
(currently POP3 or IMAP4). The user can retrieve email from the PSM at any time using 
internet standards (currently POP3 or IMAP4) user other software that can delete, further 
filter, or altogether discard the contents. 

SUBSCRIBERS may interact with the UMM at any time. 

The above passage and other text of the ‘937 provisional uses acronyms unique to that 
application and others known in the art. POP3 and IMAP4 are used in the art for known 
protocols. ASM is used to mean “authorized sender mailbox,” UMM is “user maintenance 
module,” SKE is “Spamkapu email address” and ASL is “authorized senders list.” The 
definition of PSM was not found. 



At page 5 of the final Official Action the examiner concludes: 

Examiner concludes that although some of the contents of the provisional 
application and the CIP are different, the features and elements needed to reject the 
present application are similar in both references. Therefore, Katsikas qualifies as 
prior art to reject the claims of the instant application. Accordingly, the rejection is 
maintained. 

Regarding availability as prior art of the Katsikas provisional application content that was 
not carried forward into the Katsikas publication, 35 U.S.C. § 102(e)(1) provides that "a person 
shall be entitled to a patent “unless -...(e) the invention was described in (1) an application for 
patent, published under section 122(b), by another filed in the United States before the invention 
by the application for patent,-...." 

The provisional application contents relied upon by the examiner in support of the 
Section 102(e)(1) rejection of the claims in the application were not "described in an application 
for patent, published under Section 122(b) ...." Those contents did not become a part of the 
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subsequently published '969 application. For that reasons it is submitted the ‘937 provisional 
application section relied upon by the examiner is not entitled to the "prior art date" afforded by 
102(e)(1) and does not therefore qualify to support the Section 102(e)(1) rejection by filling in 
crucial missing content of the Katsikas '969 published CIP. It is noted in passing that the 
Katsikas '969 published CIP application does not claim to incorporate the '937 provisional or the 
parent '894 application by reference. Further, nothing in 35 U.S.C. § 122(b) relating to 
publication of a pending application suggests that a preceding and unpublished provisional 
application's content should be considered to constitute any part of the application ultimately 
published under the provisions of that section. And Section 122(b)(2)(iii) indicates that a 
provisional application is not to be published under the publication provisions of 122(b). 

In the present case there is left as available prior art to support the section 102(e) 
rejection only that published content of the Katsikas '969 published CIP that was not new matter 
upon filing of the CIP. As established above, and apparently acknowledged by the examiner, 
that published CIP content does not meet the terms of the claims in this application. 

Even Combined, the Several Katsikas Applications Do Not Anticipate the Invention 

Claimed 

The above-noted second and third bases for error in the outstanding rejection are related. 
The provisional application content that the examiner cites does not relate to a proxy email 
installation method or programming such that it either (1) overcomes the published '969 
continuation-in-part application's failure in this respect or (2) teaches the features of the claimed 
invention such that an anticipation rejection would be proper if the provisional application's 
content were, in fact, prior art as respects the present application. 

It is well established that anticipation of a patent claim by a prior art reference requires 
that reference to "read on each limitation of the claim." Verdegual Bros. v. Union Oil Co. of 
Calif, 814F.2d 628, 631; 2USPQ2d 1051, 1053 (Fed. Cir. 1987). The Katsikas '969 published 
continuation-in-part application does not meet the terms of the claims of this application as the 
examiner acknowledges. However, neither do the contents of the '937 provisional upon which 
the examiner relies. 
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Each of the independent claims 1, 2, 6 and 1 1 sets forth an installation, method or 
program that includes or deals with a customer's "actual email address," and "a proxy email 
address." Neither the Katsikas provisional application nor the Katsikas parent application 
describes or utilizes two differing email addresses that can be considered to be an actual and a 
proxy email address. In each of the claims in this application, the proxy email address and the 
customer's actual email address are used in a fashion not contemplated by any of the Katsikas 
applications. Consider each independent claim in the application. Claim 1 calls for "a database 
in computer memory associating a customer's identification, a customer’s actual email address 
and a customer's proxy email address." Claim 2 calls for "associating a proxy email address with 
a customer having a customer's actual email address." Claim 6 calls for "a database in computer 
memory storing customer information in association with a proxy email address, wherein the 
customer information includes a customer's actual email address." And claim 1 1 calls for "first 
programming establishing a database for storing customer information in association with a 
proxy email address, wherein the customer information includes a customer's actual email 
address." These provisions and their association are not found in the Katsikas '969 published 
CIP, '984 parent application or '937 provisional application. Consequently it cannot be said that 
the '937 provisional application overcomes the deficit of the Katsikas '969 published CIP in this 
respect. And it cannot be said that combined the Katsikas published CIP, parent and provisional 
applications have what is necessary to anticipate the independent claims 1, 2, 6 and 11. 

As for dependent claims in the application they patentably differ from the Katsikas 
applications on the basis of their dependencies, but they do not stand or fall with the independent 
parent claims 1, 2, 6 and 11. 

Nowhere in the Katsikas applications are the recited features of claim 3 - the features of: 

(d) recording the proxy email address in a database in association with the 
customer’s actual email address; and 

(e) looking up the customer’s actual email address upon receiving the email 
at the proxy email address. 



1933741 



16 




Ally. Docket No. 15569-0007 



The examiner states at page 4 of the final Official Action: 

As per claims 3-5, Katsikas teaches recording proxy email address in a database . . 
looking up customer’s actual email address; causing a web page to be displayed; 
receiving a second email from the customer; and forwarding the second to a third party 
identified by the customer (fig 1-2 and 10-11; par 0043-0045; 0092-0094 and 0100). 

Again as pointed out above, none of the Katsikas applications teach recording proxy email 
addresses in association with actual email addresses. And the cited provisions of the published 
‘969 CIP application, even the new matter provisions thereof relied on by the examiner, do not 
describe that or the looking up of the actual email address upon receiving email at a proxy email 
address. 

Likewise the Katsikas applications do not show “causing a Web page to be displayed that 
bears the proxy email address” as called for in claim 4 or “forwarding” a “second email” (from 
the customer) to a “third party identified by the customer.” See the preceding discussion of the 
receiving and sending of email via the internet 106 in the Katsikas application. 

Regarding the dependent claims 7 - 10, as discussed above, the Katsikas applications 
describe preventing email reaching a subscriber unless the sender is on an authorized sender’s 
list. Contrary to the examiner’s further assertion at page 4 of the final Official Action regarding 
claims 7 - 10, 13 and 14, the Katsikas applications do not speak of “filtering software” (claim 7), 
a database “indication of customer’s choice” in filtering (claim 8), the three available choices of 
“no filtering,” “blocking all emails,” and “blocking objectionable emails” (claim 9), or the 
filtering choices of claim 10. 

With respect to the claims depending from claim 1 1, claim 12’s programming to identify 
a third email from the customer and for copying its content to a fourth email to the customer’s 
intended recipient is unlike anything in the email receiving and sending of the Katsikas 
applications. Pertinent here again is the discussion above respecting the error in the rejection of 
the independent claims in relation to email sent and received through the internet 106. There, the 
programming of claim 1 2 relating third and fourth emails to and from the customer is not to be 
found in the Katsikas applications. 
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As to claims 13 and 14, the preceding comments relating to claims 7 and 8 regarding 
“filtering” and “filtering choices” are pertinent. 

Dependent claim 1 5 sets forth additional details of the programming of the appellants’ 
software handling email for customers. The claim provides that “the email server is set up to 
receive all incoming proxy emails to a common catch-all account, and the email computer 
installation further comprises an email address management system that periodically checks for 
new emails for any customer.” No such feature is taught in any of the Katsikas applications. 

Dependent claims 16-18 include by their dependency the provisions of claim 15 and like 
claim 1 5 are not anticipated by any of the Katsikas applications’ teachings. These are patentable 
over the Katsikas published application and its predecessors for this reason as well as for the 
particular additional terms of these claims. 

Claim 19 is similar to claim 15, but dependent from claim 2. The claim patentably differs 
from the Katsikas applications for the reasons set forth above with respect to both claim 2 and 
claim 15. 

Claim 20 is dependent from claim 19. It is similar to dependent claim 16 and patentable 
over the Katsikas applications’ content for the reasons set forth above with respect to parent 
claims 2 and 19 and claim 16. 

Claim 21 depends from claim 20, has content similar to claim 17 and is patentable over 
the Katsikas application for the reasons stated in regard to claims 2, 20 and 17. 

Claim 22 depends form claim 2 1 . It contains subject matter similar to claim 1 8 and 
patentably differs from the Katsikas application as discussed above with respect to claims 2, 21 
and 18. 



Claim 23 depends from claim 22. It patentably differs from the Katsikas applications as 
discussed respecting claims 2 and 22 and further calls for “receiving a non-email message sent to 
the customer at a location based on publicly available proxy contact information.” This is not 
taught by Katsikas. 
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Claims 24 and 25 are dependent from claim 23 and patentable over Katsikas for all of the 
same reasons as claim 23. Additionally, unlike Katsikas, claim 24 calls for “receiving non-email 
messages comprises receiving a message by ground carrier service,” and claim 25 calls for 
“alerting the customer to the receipt of the non-email message, affording the customer the 
opportunity to request receipt of the non-email message, and forwarding the non-email message 
to the customer if the customer requests receipt of the non-email message.” Claims 24 and 25 
patentably differ from the Katsikas applications by these recitations. 

Claim 26 is dependent from claim 4. It additionally recites “step (f) [of claim 26] 
comprises saving the proxy email address into whois data for a domain name.” The claim is 
patentable by its dependency from claim 4 and by its additional content absent from the Katsikas 
application. 

Conclusion 

For each of the above reasons, the final rejection of all of claims 1 - 26 as anticipated by 
the Katsikas ‘969 continuation-in-part application under 35 U.S.C. § 102(e)(1) is in error and 
should be reversed. Each of claims 1 - 26 should be held patentable and allowed at this time. 

Respectfully submitted, 

GALLAGHER & KENNEDY 




Date: December 5, 2008 By: Thomas D. MacBlain 

Reg. No. 24,583 
Attorney for Appellant 



Gallagher & Kennedy, P.A. 
2575 East Camelback Road 
Phoenix, AZ 85016-9225 
602-530-8088 
tdm@gknet.com 
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APPENDIX A 

Claims, 37 C.F.R. § 41.37(c) (1) (viii) 

1 . A proxy email computer installation including: 

(a) a database in computer memory associating a customer's identification, a 
customer's actual email address and a customer's proxy email address; 

(b) an email server having an ability to receive a first email message at the 
customer's proxy email address; 

(c) computer executable code on a computer usable medium or media 

providing: 

(i) first programming to retrieve a customer's actual email address 
from the database upon receipt of the first email message to the customer's proxy email address; 

(ii) second programming to forward a second email message to the 
customer's actual email address, wherein the second email message is formed from the first email 
message; and 

(d) a connection to a communication link forwarding the second email 
message to the customer's actual email addresses. 

2. A method of proxy email address management including: 

(a) associating a proxy email address with a customer having a customer's 
actual email address; 

(b) receiving an email intended for the customer at the proxy email address; 
and 

(c) forwarding the email to the customer's actual email address. 

3. The method according to claim 2, further comprising! 

(d recording the proxy email address in a database in association with the 
customer's actual email address; and 

(e) looking up the customer's actual email address upon receiving the email 
at the proxy email address. 
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4. The method according to claim 3, further comprising: 

(f) causing a Web page to be displayed that bears the proxy email address. 

5. The method according to claim 3, further comprising: 

(f) receiving a second email from the customer; and 

(g) forwarding the second email.to a third party identified by the customer. 

6. A proxy email computer installation including: 

(a) a database in computer memory storing customer information in 
association with a proxy email address, wherein the customer information includes a customer's 
actual email address; 

(b) an email server to receive an email intended for a customer at the proxy 

email address; 

(c) computer executable code on a computer-usable medium or media 

providing: 

(i) first programming to detect the email received at the email server 
intended for the customer; 

(ii) second programming for retrieving the customer's actual email 
address from the database upon receipt of the email; 

(iii) third programming to forward the email to the customer's actual 

email address; and 

(d) a connection to a communication link for forwarding the email to the 
customer's actual email address. 

7. The proxy email computer installation according to claim 6, further comprising: 

(e) a filtering software in computer-executable code on a computer-usable 
medium or media for preventing an objectionable email being forwarded to the customer. 

8. The proxy email computer installation according to claim 7, further comprising, 
in said database, an indication of customer's choice or choices for an email filtering. 

9. The proxy email computer installation according to claim 8, wherein the 
customer’s choice or choices includes one of: 
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(i) no filtering; 

(ii) blocking all emails addressed to the proxy email address associated 
with the customer's information; and 

(iii) blocking objectionable emails addressed to the proxy email address 
associated with the customer's information. 

10. The proxy email computer installation according to claim 9, wherein the blocked 
objectionable email is selected from the group consisting of SPAM, bulk email, advertising, 
pornography and code to interfere with a computer's workings. 

11. A computer program for proxy email address management comprising in 
computer-executable code on a computer usable medium or media: 

(a) first programming establishing a database for storing customer 
information in association with a proxy email address, wherein the customer information 
includes a customer's actual email address; 

(b) second programming to identify a first email intended for a customer 
addressed to the proxy email address; 

(c) third programming to retrieve the customer's actual email address; 

(d) fourth programming to copy content of the first email to a second email; 
and 

(e) fifth programming operative to send the second email to the customer's 
actual email address. 

12. The computer program in a computer-executable code on a computer usable 
medium or media according to claim 1 1 , further comprising sixth programming to identify a 
third email from the customer, and seventh programming for copying content of the third to a 
fourth email for the customer's intended recipient. 

13. The computer program in a computer-executable code on a computer usable 
medium or media according to claim 11, further comprising sixth programming for filtering out 
objectionable emails. 
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14. The computer program in a computer-executable code on a computer usable 
medium or media according to claim 13, further comprising seventh programming for receiving 
a customer's choice or choices of filtering and for storing the choice or choices in the database, 
and eighth programming to recognize the customer's choice or choices and filter or not filter 
emails to the customer based on the customer's choice or choices. 

1 5. The proxy email computer installation according to claim 1 , wherein the email 
server is set up to receive all incoming proxy emails to a common catch-all account, and the 
email computer installation further comprises an email address management system that 
periodically checks for new emails for any customer. 

16. The proxy email computer installation according to claim 15, wherein the first 
programming to retrieve a customer's actual email address includes programming to check email 
addresses of all addressed and copied parties for a proxy email address being served by the proxy 
email server whenever a new email is found by the email address management system. 

17. The proxy email computer installation according to claim 1 6, wherein the second 
programming comprises programming to copy the content of the first email message into the 
second email message, the second email message comprising an email message from the proxy 
computer installation to the customer at the customer's actual email address. 

18. The proxy email computer installation according to claim 17, further comprising 
programming in computer executable code on a computer usable medium or media to effect 
deletion of an email once addresses of all addressed and copied parties have been checked for 
proxy email addresses of customers and any content has been copied to an email to the actual 
email addresses of any customers whose proxy email addresses have been found. 

1 9. The method of proxy email address management according to claim 2, further 
comprising receiving all incoming proxy emails to a common catch-all account, and periodically 
checking for new emails for any customer. 

20. The method of proxy email address management according to claim 19, wherein 
periodically checking for new emails for any customer comprises checking addresses of all 
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addressed and copied parties for a proxy email address associated with any customer whenever a 
new email is found. 

21 . The method of proxy email address management according to claim 20, wherein 
forwarding the email to the customer's actual email address comprises copying the content of the 
email into a second email to the customer's actual email address. 

22. The method of proxy email address management according to claim 21 , further 
comprising deleting an email once addresses of all addressed and copied parties have been 
checked for proxy email addresses of customers and the email has been copied to the actual 
email addresses of any customers whose proxy email addresses have been found. 

23. The method of proxy email address management according to claim 2, further 
comprising receiving a non-email message sent to the customer at a location based on publicly 
available proxy contact information. 

24. The method of proxy email address management according to claim 23, wherein 
receiving non-email messages comprises receiving a message by ground carrier service. 

25. The method of proxy email address management according to claim 23, further 
comprising alerting the customer to the receipt of the non-email message, affording the customer 
the opportunity to request receipt of the non-email message, and forwarding the non-email 
message to the customer if the customer requests receipt of the non-email message. 

26. The method according to claim 4, wherein step (f) comprises saving the proxy 
email address into whois data for a domain name. 
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APPENDIX B 

Evidence, 37 C.F.R. § 41 .37(c) (1) (ix) 

No evidence was submitted pursuant to 37 C.F.R. § 1.130, 1.131 or 1.132 nor any other 
evidence entered by the examiner and relied upon by appellant in the appeal. 
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APPENDIX C 

Related Proceedings, 37 C.F.R. § 41.37 (c) (1) (x) 

There are no decisions rendered by a court or the Board in any proceeding. 
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A system for eliminating unauthorized email sent to a user 
on a network analyzes tho sender address of incoming email 
and determines whether il is to be rejected by reluming a 
standard “no such user" error code or accepted depending 
upon executing processing rules and analyzing managed 
lists of authorized senders. This provides an advantage over 
existing anli-spam filtering systems by intercepting unau- 
thorized email before it reaches on existing email serve; or 
client The system rejects all email unless authorized by 
using a standard w no such user” error code, and by redirect- 
ing the unauthorized email back to the sender or to a sender 
evaluation site. An ASL module captures authorized sender 
addresses from the user's outgoing email and other sources 
in order to update "authorized senders" lists. The system 
may employ a WBM procedure that notifies senders of 
rejected email to go to a separate website and register as 
valid senders after passing an interaction test that precludes 
automatic registration by a mechanical program, A destina- 
tion proxy omail address procedure allows subscribers to use 
temporary proxy addresses for receiving email expected 
from unknown sources and instantiates senders as autho- 
rized upon receiving the expected email to the proxy 
addresses. The unauthorized-email rejection component can 
be readily configured as a hardware or software appliance 
used in tandem with a conventional email server, email 
gateway, or firewall to an intranet, or as a software extension 
to an existing firewall system. 
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fig 9 

QU~al 2 



coT 

Using FROM email address 
supplied, loop through each fine 
ol the ASL until thereto a pattern 
. match in Btia field „ 



Ln ___ 902 
Once there to a pattern 
match, execute Che 
contfltlon based on the 
code In this Held 



email patten 



|mom@gte.nek [always 



Get ComUtkxi- 



condttton 



Execute 



sale3@3Grne.CQrn 
[ohn@honne.CQm 
*@eol.corn 



activerenge 
(2/5/2 CUM, 
6/5/2004) 
before 
112/1/2003) 



-Get Action— * 



ASL Table (example) 



action If true 

1 friend 



903 

If the condition returns TRUE, 
execute the action based on 
the code In this field and exit 
by returning the value that 
was resulted from this action. 
If condition returns FALSE, 
continue looping through each 
email pattern. 



Comment 



[tiwnd 







friend 



I email (SPAMMErT 

rnoaol'tx H — 
femaUtmother 

fspammer, 

|blacklisl.bd, 

*@%domain% 
1%SENDER%, 



Vm working with this businessperson 

only from Feb 5 to June 5 

After 12/1/2003, 1 do not want 

messages from this address 

email we get from aol gets send back 
with an explanation _ 

pun a 3rd party software, mark as a 
spammer, send a standard message 
[to die system's administrator, and 
mark it as coming from spamkapu's 

administrator 

my birthday falte on 3/17, so tram 
1 3/14 to 3/20, 111 let anyone pass 
1 ih to wish me a happy UL11 



..larkas spammer, send nere s hi 
to contact usT message, return ’No 
irfi user** error, tnitlaliza WBM, 



0£VlS 



Execute 



condition 


syntax 

always 


return true always „ 




flrlh/wjmge 


ectiverange {low 
data, high date) 


true if today is within a range 


if today >= %1 and today 
c=%2 then return(truc) 


runoode 


runcode(flIen am e ) 


runs long and lengthy CPdo 
program 


exec(nie.pO 


black hole 


blackholep 


3rd party software to check 
against a black hole list 


exeef Wackhole.exe) __ 


before 


before (date) 


true If today is less than date 


if today <* %1 then 
return ft ruel 



Action Table (example) 

action id syntax description 



amaij 


emailed ent, file) 


return parml as kJentif sr, get 2nd parameter as a 
filename, translate and email it. 




errormsgeOdenl, file, 
errorcode) 


return parml as identifier, get 2nd parameter as a 


external 


execftDe) 


execute 2nd parameter as an external 3rd party 
software package and return its result as the 


email rtn 


amaittmolhar (Want, 
filename, to. from) 


return parml as identifier, get 2nd parameter as 
filename of message text, send It as an* email to 4th 
parameter, end use 3rd parameter as FROM ^ ■ 


friend 


retum(SPAMMER) 1 


return value cs FRIEND, no parms neecea 


spammer 




return value as SPAMMER, no perms needed 





4/(''ne«,7^C/P 



Dec 01 OB 05 : 1 6p 



Thomas D. MacBlain 



60S 698 8222 



p. 13 



Patent Application Publication 



OcL 9, 2003 Sheet 11 of 18 US 2003/0191969 A1 




FIG 10 A: 



1001 

Subscriber makes 
request vte Web 
browser interface tor 
SkPtcay emai 
addressee etong with 
desired usage 



1002 

SkProxy cmaB adtfrusues 
and associated 
characteristics are 
created end looged Into 
database 

1 



FIG 1 0B: 



1003 

Subscriber uses 
ShProxy cmaB 
addresses 33 needed or 
rnijjestod by various 
vendors ondtof services 



1004 

Servtca/Vendor send* 
email U> SkPmxy email 
nddr est 



1005 

Sk Proxy rooeives hearing crm*l with 
toe destination address set to SkPioxy] 

emol address previously given OJt 



FIG 10C: 



-Entry does not west 



i. 



fr-»nomfrvj 

~Emaf 



1007 

J Lookup To* address and attempt I 
to match against proxy address In 
SKIT end trench based return 
result 



, Entry exists 



1006 

| Rewrite "ic” address | 
to bo subscriber's 
1 actual email address | 
as recorded h> 

preprocessor table 




No Entry 



1013 

Examine SKIT end compare the 
number of senders using We proxy | 
against Ihe maximum senders 
laAowabte set by toe user and brenchj 
on too result 



1012 
Create 

j tnstanUaSon entry 
In 5KTT 



J- 
1011 

Insert appropriate entry | 
In ASL tet^a « dlrert 
by action fields tn STK 
table 



Humber of instantiated proxfc3_ 
"is loss than maximum senders 



■Nunber ol existing instantiated proxies equate or exceeds maxhmm senders 
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SYSTEM FOR ELIMINATING UNAUTHORIZED 
ELECTRONIC MAIL 

[0001] This contiimation-in-part U.S. patent application 
claims the priority of U.S. patent application Scr. No. 
09/648,894, filed on Aug. 25, 2000, entitled “System for 
Eliminating Unauthorized Electronic Mail”, which claimed 
the priority of U.S. Provisional Application No. 6 0/150.025, 
filed on Sep. 1, 1999, entitled “Unwanted Emdl Filieriag 
System”, and U.S. provisional Application No . 60/180,937, 
filed on Feb. 8, 2000, entitled “Unwanted Email Filtering 
System”, all by the same inventor. 

FIELD OF THE INVENTION 

[0002] This invention relates to a system for eliminating 
unwanted emaQ, and particularly to one in which all email 
must be recognized as scnl by an authorized sender in order 
to be accepted. 

BACKGROUND OF THE INVENTION 

[0003] Unwanted or unauthorized email is a significant 
bane for users on worldwide networks, such as the current 
public Internet. Once a person's email address becomes 
known in a network system, it can easily be replicated in 
computerized lists and passed on electronically to an unlim- 
ited number of parties who have not been authorized or 
invited to send email to the user. A user's electronic mailbox 
can become inundated with such unauthorized email Unau- 
thorized or unwanted email is referred to genetically in the 
industry by the term “spam", although the term is not 
intended to be associated with or to disparage the popular 
canned meat product sold under the trademark “Spam” by 
Hormel Gorp. The user may have an email address with a 
commercial information service provider (ISP) service 
which limits the amount of email that can be accepted and/or 
stored or which charges the user by the volume received. 
The user may also waste a significant amount of time 
opening and reviewing such unwanted cmaiL Unauthorized 
email may also be sent by unscrupulous persons who may 
enclose a virus or noxious software agent in the email which 
can infect ihc user's computer system, or which can be used 
as an unauthorized point of eatry into a local network system 
that handles the user's email. 

[0004] Most, if not all, of the current software to control 
the receipt of spam is based upon the use of identifying lists 
of known spam sources or senders (“spammers”). Such 
conventional spam control software functions on the basis of 
receiving all email as authorized unless a sender is identified 
as being on lbe exclusion list and the email can bo filtered 
out. This approach is only as good as the identifying 1st and 
cannot guarantee that the user will cot receive spam. Spam- 
mer lists require frequent updating and must be distributed 
in a timely manner to all subscribers to the spam control 
software or service. Sophisticated spammers frequently 
change their source Internet address, and can defeat attempts 
to keep exclusion lists current They can also route the 
unwanted email through the Internet servers of other patties 
so as to disguise the source of the emails through innocuous 
or popularly recognized names. A user’s email address may 
also become known to large numbers of individuals in public 
chat rooms or on public bulletin boards. Unwanted email 
sent by individuals are not tracked on spammer lists, because 
the sending of email by individuals is technically rot spam- 
ming. 



SUMMARY OF THE INVENTION 

[0005] Accordingly, it is a principal object of the present 
invention to provide a spam control system that cannot be 
defeated by spammers who frequently change their source 
addresses or disguise themselves by routing email through 
other servers, or by individuals who send email that ate not 
invited or authorized by the user. It is a particular object of 
the invention that the system of the invention rejects all 
email as unauthorized unless the sender is recognized as 
being on the user's acceptance list. 



[0006] In accordance with the present invention, a system 
for eliminating unauthorized email sent to a user on a 
network comprises: 

[0007] (a) an email client for allowing the user to 
receive email sent on the network addressed to a 
unique email address of the user, 

[0008] (b) an email-receiving server connected 
between the network and the email dient for receiv- 
ing email addressed to the unique email address of 
lbe user, 



[0009] (c) an unauthorized-email re 
nent havingje authorized senders li; " 
"Wtncn main 






dresses of senders autho - 
rs to send email to fh« user.. wfirrain the unau- 
t Bonzcd-cmail rejection component is operable wi|h 
IK emau-recciving server for intercepting aoj 
MJ feeling any incoming email addressed to the email 
"aggress ot me user. - 

[0010] In a preferred embodiment, the system's ASL mod- 
ule includes an ASL rules database for storing ASL rules lists 
of authorised sender addresses and associated processing 
rales for respective subscribers of the system, a spam 
processor module for processing the ASL rule list for 
matches, and an ASL manager for creating, maintaining, and 
updating the ASL rule lists. A redirector module rejects 
email based on the outcome of the spam processor module 
processing the sender's address against the ASL rule list. 
Email rejected by the redirector module is redirected to a 
web-based messaging (WDM) website and a message is sent 
notifying the sender to visit the WDM site and confirm that 
the sender is a legitimate sender of email to the intended 
recipient. If the sender logs on to confirm tbeir status, the 
WBM component oo the site executes an interaction proce- 
dure which can only be performed by a human, in order to 
ensure that the confirmation procedure is not performed by 
a mechanical program. The ASL manager maintains the ASL 
rule lists based upon sender address data eolbeted from 
various sources and analyses of various email usage factors, 
including sent email, received email, contact lists main- 
tained by the user, user preference inputs, third parly pro- 
grams, etc. 






[0011] The invention also encompasses associated meth- 
ods of performing the above functions, as well as related 
software components which enable these functions' to be 
performed. 



[0012] Other objects, features, and advantages of the 
present invention wfij be described in further detail below, 
with reference to the following drawings: 



BRIEF DESCRIPTION OF DRAWINGS 
[0013] FIG. lA is a block diagram illustrating a standard 
Internet email system using the conventional method for 
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filtering email &om spammers (Prior Art), as compared to 
FIG. IB which shows a conceptual overview of a system in 
accordance with the present invention. 

[0014] FIG. 2 is 8 process flow diagram for a preferred 
embodiment of the anti-spam system of the present inven- 
tion. 

[0015] FIG* 3A is a block diagram illustrating a standard 
SMTP send email process (Prior Art), as compared to FIG. 
3B which shows a modified send email process used in the 
present invention. 

[0016] FIG. 4A is a block diagram illustrating a standard 
SMTP receive email process (Prior Art), as compared to 
FIG. 4B which shows a modified receive email process used 
in the present invention. 

[00171 FIG. 5 is a process flow diagram illustrating the 
operation of an anti-spam processing murine in the preferred 
embodiment of the invention. 

[0018] FIG. 6 is a process flow diagram illustrating the 
detailed operation of a Web-Based Messenger (WBM) rou- 
tine far handling email initially rejected by the anti-spam 
control. 









[00191 FIG. 7A is a block diagram illustrating a standard 
SMTP send-iecwve email handling process (Prior An), as 
compared to FIG. 7B which shows a modified Redirector 
process for handling received email, 
r 00201 FIGS. 8A to 8D are schematic diagrams illustrat- 
ing the structure and operation of the ASL Manager in the 
preferred embodiment of the spam control system. 

r002l] FIG. 9 illustrates a detailed implementation of 
examples of processing of email send/receive and u«r 
contact data into specific forms of actions taken by the ASL 
Man ager. 

[0022] FIGS. 10A to 10C are schematic diagrams illus- 
trating the structure and operation of the invention's cmari 
proxy address subsystem processing in the preferred 
embodiment of the spam control system. 

T0023] FIGS. 1IA and 11B illustrate examples of the 
implementation of processing rules and results associated 
with the email proxy processing subsystem. 

[00241 FIG. 12 iUusIrales a detailed implementation of 
how the email proxy processing subsystem converts or 
instantiates incoming email addresses that have not been 
I previously received. 

i [0025] FIGS. ISA to 13F are schematic diagrams illus- 
trating how the invention in its preferred embodiment would 
be installed/configured in existing email server architec- 
tures. 

DETAILED DESCRIPTION OF INVENTION 

[0026] In contrast to the known approaches or existing 
spam control methods of accepting all email unless listed on 
an exclusion list as unauthorized, the fundamental pnnctple 
of the present invention is to reject all email unless the rules 
processing returns a favorable response, lo this manner, n is 
possible to filter out email that comes from unrecognized 
spam mens as well as individuals who send email that is 
uninvited by the user. Unlike the known email filtering 
systems, the present invention docs not ettompt lo filter out 



the unwanted email after it has been accepted. R»tb«. JJ rp_ <pj. 
outright rejects the email at the earliest entry level 
f returning a server-lc^ »gC em>t Sft 

•TWgr ferTs transmitting th> ***** l ^ Tji , 

'invention operates on the premise that all cm2 

n Tfmmocsscd a c cording to nre-rl miff hrfnrr lhe va1ldl ^ oF ^1 

em to a ar pttf a s 

torred. Ibis provides an innerectly powerful and 100% 
ellective ‘spam control solution in an environment where 
spammers can instantaneously change their source address 
or apparent identily and individuals in public areas em 
obtain email addresses of other users and send them 
unwanted email. 

[0027] The following is a detailed description of one 
preferred embodiment of a system for implementing the 
invention concept. In this embodiment, the spam coutrxd 
system intelligently formulates the "authorized scodera 

rules list based i ]■ flnrl nrlinm nn — TV™' 

tin th e email proxy preprocessor, an ongoing analysis of the 
■user's email usago, su3i as to whom ahd with wbat fre- 
quency sent email is addressed to other users, and through 
die gathering of high-level user contact date,' such i as a user s, 
known contacts and associates identified on other lsts or 
files maintained by the user which indicate persons ronsi" 
ered js authorized. The “authorized scndcrs'^rulc^Jierm 
also be updated and manipulated by the user at any . ume 

-fM authorized sen ders tindfor associated ggeeg- 

-tth fule& While tills spccihc implemcntauon is used, and 
— CSU m™ components are provided and configured to be 
interoperable in the described ways, it is to be understood 
that the foil scope of the invention is deemed to encompass 
many other suitable modifications and yaoabons to the 
described guiding principles of the invention 






[0028] FIG. 1A is a block diagram of a standard email 
system for sending and receiving email on the Internet and 
is used to explain lhe conventional method for filtering out 
email from spammers. The system follows a standard indus- 
try protocol for handling email on the Internet, referred to as 
SMTP. Users typically subscribe with a chosen ISP for 
Internet access and related services, including email ser- 
vices. The users access the Internet through the ISP using a 
dialup or high-speed line connection and a siandardbrowscr. 
The browser includes or functions with a standard email 
client 101, such as the Outlook TM email client distributed 
bv Microsoft Corp., headquartered m Bchevue, ^h.»or 
the Netscape™ email client used by AOL Online, Fairfield, 
Va. The ISP operates at a website address corresponding to 
its domain name which is addressable by users on tbe 
Internet. TbcTSP/s service functions are performed for a 
large number of subscribers through one or more serves. 
Typically, an email server 102 is used to handle the email 
service functions. Email sent lo tbc ISP from the Internet is 
received at SMTP Server 104, where various administrative | 
functions are performed, such os chocking whether the 
addressee is an authorized subscriber of the ISP, then the 
email is placed in a storage space reserved for that user, 
referred' to as Inbox 103. When users connect to tbe ISP, they 
can retrieve ibeir email and store it with their own email 
client (on their own computer). Users can send email by 
composing it locally at their email diem, then uploading it 
lo the SMTP Server 105 at the ISP, which then routes it to 
the recipient's email address on the Internet. 
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[0029] Conventional ami-spam control can bo imple- 
mented with the SMTP Server and/or at the email client. 
Many ISPs implement an exclusion list of known spammers 
at tbe SMTP Server. In addition, they commonly allow a I 
user to filter out unwanted email from certain senders known \ 
to the user. For example, the user's email client may have a 
filtering function that allows the user to input unwanted 
sender email addresses to the SMTP Server so that email 
received by the SMTP Server can be filtered out before 
being pul into the user's Inbox. Further, independent soft- 
ware vendors sell sophisticated email handling programs 
that work with tbe user's email client For example, some 
handling program have functions for categorizing received 
email into topical file folders, and email from unrecognized 
senders may be pul into a "Miscellaneous" or “Unrecog- 
nized” file folder. 

[0030] In FIG. 1B> a conceptual overview of a system in 
accordance with tbe present invention is shown. As before, 
the standard email client 101 is connected to an email server ' 
102 for sending and receiving email to and Grom tbe Internet 
via SMTP Server 104 and Inbox However^ jq ihta^ 
modified J O pdf ailUH, the pr&sent invention provides tor an : 

" ubautbonzcd-enruil rejection component 113 upstream of 
l the existing email server which intercepts and rejects email ■ 
\ before it is »^Tf f 1 h y fefaafl s&ggSfc fa Ibc rejection^ 

1 c^npon.enl 113^u Aufocraed Sender lisfXASL) Manager 
l^piCT rcmair addresses from email sent by the 
user, as shown at block 112, -and also captures sender email 
addresses from email sent to4h© user, as shown at block 107 ■ 
The ASL Manager analyzes the captured sender email 
addresses tod recipient email addresses and employs certain 
p re-dcfined roles (described in further detail below) io add 
or remove email addresses from the “authorized senders" 
lisLre f erred to as the AST , jink List or Database. Tbo ASI^ 
/5UQLi st is used by thcjfePAMKAPU Server 113 to accept 

P fom'seTidcrtih^l favorably pass tbe ASL pro- 
rubsequently relays the email to the prc-cxisling 
TP email server 104 while rejecting all other ' 
“not such user'’ error code, as indicated at block; 
— — 

[0031] Referring to FIG. 2, the process flow for the 
operational steps of the anti-spam system of the present 
invention will now be described. Certain terms used in the 
description are defined below: 

[0032] SPAMKAFU: An example of the spam control 
system of the invention. 

[0033] SUBSCRIBER; A person subscribing to an ISP 
email service that is using the spam control system of 
the invention. 

[0034] FRIEND: An email-sending source that is autho- 
rized by the spam control system to send eipail to the 
SUBSCRIBER. 

[0035] SPAMMER: An email -sending source that is not 
authorized to send email to tbe SUBSCRIBER, which 
is commonly understood to be an unknown or unau- 
thorized party that is using a manual or computerized 
email list mailing program to send large volumes of 
oroails-rcpctiliVely through the Internet. 

1 [0036J UNKNOWN: An email sending source that basl 
not yet been identified as either a SPAMMER or a] 
CONTACT. I 



[0037] Email sent from the Internet (106) is sent to the 
email address of the ISP for the SUBSCRIBER, referred to 
in block 201 as the SpaiqKnry Fm^l Address fftKE)— , 
-Received email must first pass through the skproxy prcpro- I 
’ ecssor 202. The skProxy preprocessor examines the “to:" J 
I email address against a table of proxy addresses and if there A 
\ is a match appropriately processes tbe email before passing ] 
. it to tbe Redirector 203 Jfhc Redirector 203 sends a request 
I for validahUU fin Lite Em ail from the Spam Processor 204 
which maintains the Spam Processing Database (SPDB) 

205, including the Authorized Senders Rules List (ASL) 

206. The SPDB Database and ASL Rules List are the heart 

of SPAMKAPU, as they contain the processing rules and 
lists of persons authorized to send email to the respective 
SUBSCRIBERS of the system. The Spam Processor 204 
sends a response, either that the sender's address on the 
email is not authorized on tbe ASL List, ix., is a SPAM- 
MER, or is authorized on the AS1 niley list. a % 

F gJJ’Kni^ fsF \A present a! ail on the. A.M. rales iisL Lc. is/, 

flfUN KNOWN. ] f the response is that it is a SPAMMER, tbe 
l- Rudlfcclor 2U3 rejects tbe email, as shown at block 207, such 
as by sending a standard error message to the sending server 
that the user as addressed does not exist. 

[0035] As a refinement to the system, a Web-Based Mes- 
senger (WBM) process at block 208 may be set up to 
provide a corrective pr ocedure in the eve nt that the reiccjgL 
in frftir aomfioaeJot vet listed on the. ASL list md 
TtE erefbre an UNKNQWNj The unauthorized email may 
nflually u bc trom a person who has not been previously 
processed in the anti-spam system but wbo has a legitimate 
reason to reach the SUBSCRIBER. The WBM process 208 
is set up as part oE the sp am control syste m to which the 
rejected email is redirected! !* WBM process then sendsan 
rhp ymail-gaaiirr who is now treated as an 
iUNKNOWNy or example, the email message may read; 

[0039] “An email sent by you to SUBSCRIBER’S 
1 address was redirected to this site as being scut from 

! an unrecognized sender address which may be a 

I source of spam email. If you would like to confirm 






A &S 






[0040] The WBM pay^ ha yc a sep arate web site address, 
for interactions witl^^SoW^Whcn a nfiNXNOWNJ 
receives the error response email, if they are a legitimate 
FRIEND for the SUBSCRIBER, they may elect to go to tbe 
WBM sitcuo confirm their status as a legitimate FRIEND. 

If done before tbe expiratioo date, the WBM process will/ 
add an cmry ihfotbc ASL rules list so that the now validated r 
FRIEND mavfoh mcd the previous email and scnjLfUjTO - 
emails without orroiul sbuWiJ In btodc jSOP.’U' lflCSUSPECT 
does not respond, this fact is also sent to tbo ASL Manager 
for further analysis. The extra confirmation step effectively 
eliminates SPAMMERS since they use automated programs 
to send out batch email and typically will not take human 
response lime to log on to the WBM site to confirm tbeir 
legitimate status. 

[0041] If the Spam Processor scads a validation response 
that the sender is a FRIEN D ihen the Rcdirgqor 203 passes, t 
the em ail to tbe designated existing SMTP seivcr 2U which 
i*tTf0CCHfidT lbc~email accordance with existing Internet stan- 
1 dards fRFCB2lT The user can now collccl lbeir email their , 
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standard Inbox 212 (using standard Interne} protocols such 
as POP3 or IMAP4) through the user email client 101 on 
their computer. Tbeir email is 100% spam -free, since all 
email from senders not recognized by the system as autbo- 
been — 

[0042] Users send email composed on and sent from the 
email diem 101 via standard SMTP protocols to the ISP's 
email server. The ISP's SMTP server is responsible for 



providing users with email addresses within the system, and 
sending users’ email to the recipients' email addresses on 
the Internet 103. In the SEAMKAPU invention system, an 
SMTP Send Manager 214 is provided to intervene In the 
usual send email process. The SMTP Send Manager 212 
copies header information from all outgoing email and sends 
the data to ibe ASL Manager 213, then sends the email on 
to the ISP's existing SMTP server which in-turn sends the 
mail to its intended destination as shown in block 215. The 



ASL Manager 213 performs one of the key fonctions in the 
invention system. It analyzes the header data from sent email 
and data from other data sources 216 maintained by the ISP 
email server system, such as email logs and user-supplied 
lists. On Ibe basis of its analysis routines (to be described in 
further detail below), the ASL Manager 211 checks, popu- 
lates, and updates the SPDB Database and ASL Rule List 
with the email addresses and other data on senders autho- 



rized to scad email to the SUBSCRIBERS. The SPAM- 



KAPU system also includes User Maintenance Modules 
(UMM) 217 which allows the user to interact with and 
upload user information to SPAMKAFU far further cus- 
tomization of SPAMKAPU's email operations for the user. 



[0043] Referring to FIGS. 3A and 3B, a standard SMTP 
send email process (Prior Art) is shown compared to a 
modified send email process used in the present invention. 
Id the standard send email process, in FIG. 3A. email sent 
from the user's email cheat to the ISP’s email server may be 
pre-processed, such as che ck ing for correct syntax, alias 
expansion, eta, and to identify the list of recipient email 
addresses (could be 1 or more). The server email manager 
gets each recipient email address in turn and attempts to 
establish a connection to the destination SMTP server and 
verify if the recipient email address is proper. If negotiation 
is unsuccessful, an error message is returned to the sending 
SMTP server. If negotiation is successful, the sending server 
sends the message body to the destination server and per- 
forms a proper “close connection'' operation. In the modified 
send email process of the invention, in FIG. 3B, the email 
sent from the client is prc-proccsscd by the SPAMKAPU 
SMTP Send manager 214 which copies the all recipient 
email addrcss(cs) including but not broiled to the TO: CC: 
and BCC:'* addresses and sendk the data to the ASL Manager 
213. The SPAMKAPU SMTP Send Manager then passes the 
email to the existing ISP email server for transmission to the 
actual desUnation(s). On the assumption that the SUB- 
SCRIBER authorizes email to be received from any person 
tho SUBSCRIBER has sent email to, the proper email 
addresses of persons to whom the SUBSCRIBER has sent 
email arc added to the ASL list of persons authorized to send 
email to the SUBSCRIBER. The sent email data can be used 
in further analyses by the ASL Manager, e.g., to upgrade a 
person's authorized status from temporary to permanent if 
more than a threshold number of email is sent by the 
SUBSCRIBER to the same person. 



[0044] Referring to FIGS. 4A and 4B, a standard SMTP 
receive email process (Pribr Art) is shown compared to a 
modified receive email process tacd In the present inven-i 
tion. In the standard receive email process, in FIG, 4A, 
email is received by the SMTP server from sender sources 
on the Internet and the server stores the email in the user's 
Inbox. In the modified receive email process of the inven- 
tion, in FIG. 4B, the received email is subjected to process- 
ing by ibe skproxy and redirector as shown in blocks 202 
through 206 to determine the nature of the sender's address 
(FRIEND. SPAMMER, or UNKNOWN). Even though the 
sender is already on the ASL authorized persons list, the 
received email data can be used in further analyses by die 
ASL Manager, e.g„ lo upgrade a person’s authorized status 
from temporary lo permanent if email from that person is 
received on an ongoing basis and has not been ch&oged by 
the user. The SMTP receive email process then sends the 
email to the existing SMTP server via standard (rfc821) 
relay protocols for normal processing. 

[0045] In FIG. 5, n process flow diagram illustrates the 
operation of the Spam Processor 203. At block 501, a request 
from the calling routine, here Redirector 203, seeks valida- 
. tion whether a received email is from an authorized sender. 
The request identifies the parameters who the email is 
FROM and who il is sent TO. The Spam Processor 204 uses 
the TO address to lookup that user's ASL List 206 in the 
SPDB Database 205, as indicated at block 502. The lookup 
procedure follows a loop 503 of reading the next ASL record 
on the user’s ASL list, checking for a match lo the email 
FROM address (authorized person), reading the next .record 
if there is no match of the current record, executing the 
match condition by issuing a TRUE value if found, other- 
wise returning for the next record, as indicated at block 504. 
At block 505, if a TRUE VALUE is issued, then at block 505 
the action is taken of executing the processes as defined in 
the Spam Processing Database or SPDB for this particular 
FROM/TO combination. Examples of processes include 
setting the output value to cither FRIEND, SPAMMER, or 
UNKNOWN but also may indude the execution of 3 rd party 
software that may determine a FROM source is blacklisted 
or even determining that the email contains viruses. At block 
506, the returned value is sent as a message to the calling 
routine, Le., the Redirector 203. If the relumed value is 
UNKNOWN, a standard error message is induded. As a 
default option, if no ASL list is found for the user, the system 
returns the value FRIEND, as indicated at block 507, in 
order to allow the email to be accepted as a temporary 
coudi lion until an ASL list can be established for that user. 
The request processing routine can be implemented using 
industry standard PERL programming syntax and incorpo- 
rating a PERL interpreter to execute the processing roles. 
[0046] In FIG. 6, a process flow diagram illustrates the 
detailed operation of the Web-Based Messenger (WBM) 
routine for handling email rejected by the Redirector 202 
(see FIG. 2). Preferably, the WBM process is implemented 
via interaction with a rejected sender at a separate Web site 
address. In Phase I , corresponding to step 204 in FIG. 2, the 
WBM process is initialized at block 601 by the ASL rule 
returning a value for rejecting an email as sent from ao 
UNKNOWN by the Redirector 203. At block 602, a unique 
ID number is assigned to the UNKNOWN sender’s email 
address in the WBM database and a given expiration date is 
set, e.g., 48 hours. At block 603, a return email is sent back 
to the sender's email address in ordor to notify the 
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UNKNOWN lo go lo the WBM web page if they wish to 
follow through with coo lading the SUBSCRIBER. The 
WBM then waits for the UNKNOWN to go lo the WBM site 
lo oomplcte ibo process, referred lo as Phase 2. At block 604, 
the UNKNOWN accesses the WBM web site and agrees to 
the displayed terms and conditions of usage. At block 603, 
the WBM process verifies th&L the time for response for the 
email corresponding to the ID number has not expired. The 
WBM then follows & lest procedure to ensure that the 
responding UNKNOWN is not being implemented by a 
mechanical program. For example, at block 606, a word or 
question stylized in non -standard font can be delayed as a 
graphic image, and at block 607 the SPAMMER is prompted 
to type the word or answer the question ibal appeals in the 
graphic. A mechanical program would not be able to read a 
graphic image of a word in unrecognizable font or would not 
be able to answer the question. At block 608, if the WBM 
process determines that a correct word or answer has been 
typed, the UNKNOWN status is upgraded lo FRIEND on 
the user's ASL Rule list At block 609, the WBM process 
notifies the FRIEND that he/she may re-send their original 
email and/or other email to the SUBSCRIBER. At block 
612, if the SUBSCRIBER determines that the email is from 
someone whose email should be rejected without a WBM 
error reply option, the SUBSCRIBER may optionally down- 
grade the status permanently to SPAMMER through the 
UMM 214. 

[0047] Referring to FTG. 7 A, a block diagram illustrates a 
standard SMTP scnd-roccivc email handling process (Prior 
Art), as compared lo FIG. 7B which shows a modified 
Redirector process for handling received email. In the stan- 
dard process, the Scndei-SMTP 701 requests connection to 
the Receiver-SMTP 702, which accepts the connection if 
available. The Sender SMTP then performs the task in its 
Send Email loop of sending the recipient's email address. At 
block 703, the Receivcr-SMTP confirms or denies whether 
the recipient exists ox whether it has authority to process 
email for this user. If confirmed, the Sendcr-SMTP sends the 
message body and marks the end of the message. At block 
704, the Rcccivcr-SMTP receives the message body and 
sends it to the email box of the recipient (or recipients if the 
message is sent to more than one recipient at that SMTP 
server address, 

[0048] In FIG. 7B, the Scndcr-SMTP 701 and Receiver- 
SMTP 702 perform their usual establishing of a connection 
and check for valid recipient e-mail address. However, in 
this modified process implemented in conjunction with the 
Spam Processor 705, the sender's email header information, 
including the FROM address is stored by the Spam Proces- 
sor for later use, as indicated at block 706, At block 707, the 
sender's PROM address and the recipient's TO address are 
sent to the Spam Processor 705, by a request for validation 
by the Redirector as described previously. At block 708, 
after checking the recipient's ASL Rules list to determine the 
status of tbe sender, the Spam Processor can return a 
response of FRIEND or a response of SPAMMER or 
UNKNOWN with an accompanying error message. If tbe 
response is FRIEND, an output is sent to the Scnder-SMTP 
confirming that the email can be received, and the email is 
sent to the Recelvcr-SMTP as usual. At block 709, the 
Recerver-SMTP relays the email to the recipient's email 
server for standard inbox processing and, if desired, can 
include a message noting that the sender was identified on 
the ASL list as a FRIEND. If the response is SPAMMER, 
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then an error message is returned to the Scnder-SMTP that 
the recipient does not exist or the Recipient-SMTP is not 
authorized to accept the email. If the response is 
UNKNOWN, the Rcccivcr-SMTP may send the email 
through the WBM process, as described previously (Indi- 
cated at block 710), if the response from Ihe Spam Processor 
indicates that the status of the sender is an UNKNOWN 
sender (as opposed to having the confirmed status of SPAM- 
MER). 

[0049] In FIG. 8A, a schematic diagram illustrates the 
structure and operation of the ASL Manager, previously 
described as component 211 with respect to FIG. 2 . The 
ASL Manager preferably is structured to have an ASL 
Oo-Dcraand Processor 801 and an ASL Scheduler Processor 
802, both of which utilize industry standard XML and Web 
service protocols to interact with an ASL Rules Processor 
806, winch also exchanges data with the Spam Processor 
Database (SPDB) 205. Email addresses sent to and received 
from tbe SMTP Send Manager 214 and SMTP Receive 
Manager 211 are processed by the ASL On-Demand Pro- 
cessor 801 which executes the appropriate rules in conjunc- 
tion with tbe ASL Rules Processor 803. Content from a 
variety of other sources, including compatible third party 
plug-ins, can also be processed to create, populate, aod 
update the ASL lists stored in the SPDB 205. For example, 
content may be received from a "Drag and Drop Manager" 
for conveniently handling user address inputs while working 
with the email client, user address inputs from Web sites 
While working with an. associated browser, addresses added 
by the user to a desktop contact manager, such as tbe 
Microsoft Outlook TM Address Book, ot other contact lists, 
and other address inputs generated by third party software 
that can operate with the user's client programs. 

[0050] Tbe ASL Scheduler Processor 802 is used to pro- 
cess tasks on a scheduled basis for various analysis and 
maintenance functions. This allows a very rich examination 
of the SUBSCRIBER'S ASL list, mail log, and other data 
files, to continually refine the “authorized senders" list for 
accuracy and relevance. For example, the processor func- 
tions can include: an ASL Mail Log Analyzer for analyzing 
ihe ASL Mail Log database 804 of the SUBSCRIBER'S 
received and sent emails; an Expiration Date Analyzer for 
setting and enforcing expiration dates for authorized senders 
to be re-authorized; a Low Mfiume Analyzer for downgrad- 
ing or eliminating the authorization status of senders with 
whom the SUBSCRIBER communicates very infrequently; 
a High \blumc Analyzer for upgrading or permanently 
marking the authorization status of senders with whom the 
SUBSCRIBER communicates very frequently; a Fuzzy 
Logic Analyzer for making qualitative decisions as to 
FRIEND or SPAMMER status based on a variety of factors; 
and other Third Party Analyzers for analyzing data gener- 
ated by third party plug-ins and programs to refine the ASL 
list. 

[0051] The ASL Rules Processor 806 contains the rules (in 
an ASL Manager Rules Database 803) that determine how to 
add, update or modify the ASL Lists maintained in the SPDB 
Database 205. The Rules Processor can have an architecture 
that readily accepts and interoperates wiib third parly data- 
bases 805 and applications programs 807 in order to harness 
the collective power of developed in the network commu- 
nications industry to continually improve and extend tbe 
SPAMKAPU system's feature set. The ultimate result of this 
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architecture is to enable the creation of a very richly detailed 
ASL database which goes beyond even the total elimination 
of spam email into other or future needs of users lor the 
dynamic and intelligent handling of email. 

[0052] FIGS. 8B> 8G, 8D, illustrate various configurations 
where the invention interfaces with 3 Td parly services and 
software- FIG. 8B illustrates a specific example of how the 
on-demand processor operates. In this ease, 3 rd party soft- 
ware installed on the subscriber's client computer 810 
gathers all email addresses stored in an application such as 
Microsoft Outlook, then connects to the spamKapu server 
using an XML interface 811 and uploads the contacts into 
the ASL Rules database 812, marking them as 41 Friend’ 1 . 

[0053] FIG. 8C illustrates a specific example of bow the 
ASL Scheduled Processor invokes an XML interface 811 to 
connect to a remote 3 ,d party service 815 to perform a 
detailed analysis of the ASL Rules database. Updates to the 
database arc transmitted back by XML interface 815 to 
update the ASL Rules database 812. 

[0054] FIG. 8D illustrates a specific example of how tbe 
ASL Rules database can utilize a 3 ri party to analyze email 
in real-time. As email is received by tbc SpamKapu server 
818 an ASL Rule is invoked to used a 3 rd parly 819 and uses 
an XML interface 811 to connect to a 3* d party real-time 
email analysis service 821 which may employ sophisticated 
pattern matching analysis, for example. Tbe service 821 uses 
an XML interface 811 to return a result of SPAMMER, 
FRIEND, or UNKNOWN 823 which is then further pro- 
cessed by the SPAM PROCESSOR 204. 

[0055] In FIG. 9, □ detailed implementation is illustrated 
of examples of processing of email send/rcccivc and user 
contact data into specific forms of actions taken by the ASL 
Manager. Tbc basic process How consists of: Step 901 of 
looping through each line of an ASL rules list (called a 
Table) comparing tbe FROM address captured from ao 
incoming email for a match; Step 902 of determining 
whatever condition or status flag has been set for the 
matched entry, then executing the corresponding condition 
rule as maintained on the Condition Thble, resulting in return 
of a Return Value; and Step 903, based an tbc Return Value, 
executing tbe corresponding action rule as maintained on the 
Action Table, and exiting with a Final Return Value from 
this action. To follow one example through Uus process flow, 
Step 901 finds a FROM match of tbe sender address 
jobD@bomc.com, Step 902 notes the expiration date condi- 
tion “before Dec. 1, 2003” and executes the “before" con- 
dilion on the Condition Table to return a value of 'True” if 
today's dale is less than tbe indicated expiration dale, and 
Step 903 notes that tbe sender status action (if condition is 
True) is “friend” and executes the “friend" action on the 
Action Table to return a Final Return Value of FRIEND (no 
parameters needed) as the validation response of tbc Spam 
Processor. 

[0056] The specific programming syntax or execution 
logic of the ASL Manager rales processing may be varied in 
any suitable manner depending on the developer of the 
Spam Processor application. Tbc following examples of 
some options for ASL Manager actions illustrate a wide 
range of approaches that may be used: 



[0057] MATCHING AN EMAIL ADDRESS OR 
ADDRESS PATTERN: 

[0058] (a) Default; exact match 

[0059] (b) A specific email address: 

john@company.com 

[0060] (c) UNIX Standard wildcard matching: 

[0061] * .tnicrosoft.com-anything from 

“Mkrosoft.com" 

[0062] micro soft* -anything with microsoft in it 
[0063] "‘.mil-any email from the military 

[0064] (d) Matching any known “blackbolc list" 
by using a %BLACXHOLE% symbol. 

[0065] USING A CONDITIONAL AND PARAM- 
ETERS TO EXECUTE IF THE MATCH IS TRUE 

[0066] USING A SECONDARY ACTION AND 
PARAMETERS TO PERFORM IF THE CONDI- 
TIONAL IS TRUE. 

[0067] USING THE LAST DATE THE SUB- 
SCRIBER SENT EMAIL TO THIS ADDRESS 

[0068] USING THE LAST DATE THIS ADDRESS 
SENT EMAIL TO THE SUBSCRIBER 

[0069] USING DATE THE RECORD WAS CRE- 
ATED 

[0070] EXAMPLES OF CONDITIONALS THAT 
CAN BE USED 

[0071] (a) Expiration dates; use a given address 
until Feb. 12. 2004 

[0072] (b) Date ranges: use a given address from 
Apr. 1, 2004 to May 2, 2004 

[0073] (c) Specific recurring times: first week of 
every month but no other time, e.g., 
ncwslctLci@magazinc.com acceptable during l” 1 
week of each month. 

[0074] (d) A link to external software designed to 
allow for additional user-defined criteria; this 
allows for third party applications 

[0075] EXAMPLES OF MESSAGES THAT MAY 
BE INVOKED BY A GIVEN SECONDARY 
ACTION 

[0076] (a) Standard “crrai" 

[0077] (b) Cistern with variable substitution in the 
message body, c.g.: 

[0078] %usenume% is substituted with the 
sender's email address 

[0079] %subid% is tbe ID code of the subscriber 
[0080] %datc% is today's date 

[0081] (c) “hello %uscraamc% you have been 
identified as spam, go to totp://www.spamkapu* 
.con/subscribcr=%subid% and if you're really 
human we'll lei you in. 

[0082] (d) Custom text: “All email addresses from 
America Online arc unconditionally rejected” 
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[0093] (e) Send a given message in the error 
response. 

[0084] (£) Send a given message as an email. 

[0085] (g) Open a file and email its contents 

[0086] (b) Open a file and send its contents as an 
error rcponsc. 

[0087] (i) Set the sender's stains to SPAMMER or 
FRIEND 

[0088] (j) Create a unique ID that will expire after 
a short time period (24-48 hrs). This id can be used 
by the SUSPECT Co access the WBM and become 
a CONTACT, 




[0089] (k) Give SMTP default error message 

[0090] (I) Link and execute external software 
designed to allow for additional user-defined 
_ actions; this allows for third party applications. 

[0091] In FIGS. 10A and 10B, a schematic diagram 
illustrates tho structure and operation of the SkProxy email 
preprocessor. The preprocessor simplifies the method by 
which users can manage their ASL rules list in situations 
where the user may wish to receive email from source whose 
“FROM:” email address is not known. Examples of such 
include subscription to newsletters where one supplies their 
email address to a newsletter service without knowing the 
correct "FROM" address until the newsletter is actually 
received, and online ordering procedures that request a user 
email address for the purposes of sending a confirmation 
email but do not disclose their “FROM” email address. Tbc 
preprocessor is an additional software module that is 
designed to reside on the same server as the other SpamKapu 
software. All incoming email is first processed by the 
SkProxy processor and then passed on to other SpamKapu 
software modules as warranted. 

[0092] FIG. LOA illustrates the first phase of the general 
SkProxy process whereby in step 1001 a user uses a standard 
Web browser to conned to the SpamKapu server, then 
requests and is given a Hsl of “Proxy" email address which 
do not directly disclose or identify the user's actual real 
email address step 1002. As an alternative, the user may also 
first create tbeir own proxy email address, then enter that 
address into the SKT (FIG. UA) via a Web ioterfoce. This 
liberates the end-user from having to obtain email addresses 
beforehand. These Proxy email addresses along with their 
characteristics are stored in a tabic shown in FIG. UA. 
hereinafter referred to as tbc “SKT*. 

[0093] In the second phase shown in FIG. 10B the end- 
user gives out these Proxy email addresses step 1003 as 
needed to subscribe to newsletters or other situations where 
the “FROM;” email address is not known. When the entity 
that has received this proxy email address wants to send an 
email to the end-user, they can only send it to the proxy 
email address step 1004 because that is the only address they 
have on file. The SkProxy process is the first to receive the 
email in Step 1005. 



[0094] Control is then passed to FIG. 10C, step 1007, 
decide if the proxy address has been instantiated or not by 
examining the SkProxy Instantiation Tabic, described in 
FIG. UB and hereinafter referred to as the SKIT, and use t he 
proxy and sender addresses to find a match in tho SKIT. If 
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an entry does not exist (meaning that it has not been 
instantiated), then in step 1013, SkProxy counts the number 
of number of senders using this proxy address by examining 
the SKIT and determine if the number of instantiations has 
reached the maximum allowed as defined by the user in the 
SKT. If the maximum has not been reached, it instantiates 
the proxy address by creating an entry in the SKIT, as 
detailed in FIG. 12 and step 1012. In Step 1011, it references 
the entries in the SKT table along with the senders FROM 
address to create app r opriate entries in the ASL Rules list as 
detailed in FIG. 12. In Step 1008, it rewrites and updates the 
“TO:" address to be tho actual address of tbc end-user and 
in Step 1009 adds the proxy email address in the end-user 
name area so that the end-user can see wfaat proxy email 
address was used by the sender. Step 1010 passes control to 
the Redirector which may now properly evaluate the From/ 
To: combination and perform the correct processing The 
email will now be accepted by the SpamKapu server 
because (he instantiation process has created created appro- 
priate ASL rules that will allow this email to pass through 
without requiring WBM validation. 




[0095] If tbc maximum instantiations bas been reached as 
determined by step 1013, SkProxy docs not instantiate any 
further proxy entries and passes control to step 1010, return- 
ing to the Redirector. The act effect of disallowing further 
instantiations will be that no ASL rules win be entered and 
since it is highly likely that no ASL rules already exist with 
this sender's email address, the sender’s email will most 
Kkcly be rejected by tbc Redirector. 

[0096] FIG. 11A illustrates a sample representation of the 
SkProxy Tkblc (“SKTO used to hold SkProxy-relaled infor- 
mation, This table's function is to record all the proxy 
available along with various characteristics that 
direct what kind of ASL entries the proxy address will create 
upon instantiation. The following describes each field: 




Label in FIG. UA Column Description 

a Praxyaddreas: tbc email address Out can be given 

out by the cod-oacr. Senders tending email to Ibis 
address vrill reach the oad-uier if the proper 
caxUitioju are met. 

b true gmail; ihc real email address of the SpamKapu 

cod -user 

c creation date: the date Ibis proxy address was 

created 

<j expiration type: Relative or Absolute. A relative 

expiration will expire this proxy based on the 
number of dates elapsed from the date of a specific 
proxy address instantiation. Alt absolute expiration 
will expire this proxy based on tbc number of dates 
elapsed from the date of initial proxy address 
creation. 

e expiration days: the amount of days to allow to 

transpire. Used in conjunction with field d above 
to if a proxy address has expired. 

f mss senders: tho maximum amount of dilXercnt 

senders that may instantiate use this proxy address. 

g pr oxy type: whether to create an ASL entry to allow 

the entire domain of U*c sender, oi oai tbc speci fi c 
email address of the sender 



[0097] The following explains the sample data presented 
in FIG. 11 A and describes their application in the SkProxy 
technology: 
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-continued 



Row Example ond de scription of use 

1 The end-user will give It but lo a person fit a meeting with the 
iotent of allowing anyone fiom that compony to rend email to the 
subscriber. When the first cmafl come* from that pen on, the 
skProary process will irtstantiale this entry, end make an cotry in 
the ASL table to allow toi any emails from this do mala to peas 
through sa "friend’*. The maximum sender* allowable is set 

to 1, so the seeder's domain will be the Rial and the only 
allowable domain (company) to use this proxy 

2 Eed-nxet has gives this proxy address lo subscribe to a 
newsletter and has defined the proxy to allow 2 different 
senders to uso the proxy email eddies*. 

3 End-oscr is creating a private m&D network to execute a i avail 
project. Because the capitation was absolute, Ihia proxy will 
expire 720 day* after Dec. 27, 2002. Up to 5 reader* may use 
tbo same proxy address. 

4 The end-user will be providing hb/hu email address al a 
corporate Web rule. When the first email comes Cram Ibat site, 

Iho tkProxy process will this entry, and make an 

carry in the ASL table to allow for any emails from that 
specific sender only to pass through as a •friend”. 

Because max senders is aet lo % the first sen del to 
instantiate the address will ako ba the only sender that can use 
that proxy address. 

3 Bad-user has given this proxy address to subscribe to o newsletter 
and has defined the proxy lo allow 2 different domains to use the 
proxy email address. The expiration is set to 0 which means this 
proxy oddresa will neve; expire. 

6 End user intends to place on cnKao order, docs not want the proxy 
to expire, and wCU allow up to 3 different lenders to uoo the 
same proxy sddresi 



[0093] FIG. 11B illustrates a sample representation of the 
SkProxy Instantiation Tablo (“SKIT”) used to hold specific 
proxy instantiation information. This table's function is to 
record each instantiation of the proxy address, especially the 
sender's email address. The following describes each field: 



Label In FIG. UB Column Description 



a Proxynddnaa: same as HO. 11A, column a 

b iosUaristior date: the dale this proxy eddtesi wu 

instantiated for thia sender 

c suadcr Id; the intbrcniikm to the left of the m <gT sign 

of the lender'* Uternet email addresses 
d wader domain: the information right of the "(gT 

sign of the tender's Internet email addresses 



[0099] The foDowing explains the sample data presented 
in FIG. IB and describes the details of various instantiations 
corresponding lo tbe sample data provided in FIG« 1LA: 



Corresponding 
row in FIG. 

R ow 11A Description 

1 2 Tbe sender umv@scmc.com sent an email to the 

proxy address ju*lforaegyc@ya mk«p u-CDtn. This 
row was instantiated as s result and subsequently 
Ttan’i email went through to the rod-user without 
requiring Lbs WBM validation. Becstise the 
column f Is Ihs corresponding row In FIG. 11A 
for this proxy address shows o fimU of 1 tender 
only Tbm can send email to 
juxtforscnic^pGnitapu. 



Cbmsspooding 
row U FlO. 

Row 11A Description 



2 



3 



4 



5 

6 
7 



com. Anyone dsn sending an email to 
justfor*cme@spamkapturom will receive an 
in dustry-eta ndard “no such uxor” error 
message. 

2 The proxy address •finandatiimeslgapsmiapu. 

com" was gives out by the ond-uscr lo ubscribo 
to a rowidnocr. This newsletter service sends out 
a confirming email before starting the subscrip- 
tion. This row’s instantiation is the result of 
receiving a cox finning email from the newsletter 
service with a “FROM" address of “confirm® 
subscriberijcom**, which passed through to the 
end-user without requiring WBM validation. 

2 This row'i instantiation is the result of receiving 
the actus! newsletter. A second email from the 
newsletter service with a "FROM" address of 
**ucw 9 lsttect@cabscribere«aaa% which posted 
through to U» end-user without requiring WBM 
validation. SAsequent newsletters have the same 
"FROM" address and therefore do not a rate 
ndditloaal instan tio don records and oho paw 
through wilhool WBM valWadoa Because the 
max senders field in column f of the corre- 
sponding row in FIG- 31 A is set to 2 sad 
because there are 2 entries in this table, 

any other emu) sett to tbo proxy address 
^nmurialrim ia@q3ainkBpaxoar , will 
nut be instantiated in the SKIT table, no ASL 
roles will be created, sad as a result the 
SpamKapu server will return »a industry standard 
"no such user" error message. 

3 Rows 4, 5, and 6 illustrate 3 different lenders that 
am using the same proxy address. Emails from 
these senders will pass through wilhool a WBM 
process. Because the corresponding entry in the 
SWT table shown in FIG 11A, row 3 column f, 
indicates that there ire 5 max readers allowed, 
and there are only 3 different senders in this 
table, 2 mom different senders may send an email 
to Wr74352@spomkspu.corr] without requiring 
WBM validation. After the 2 additional hmautia- 
tfoos hove occurred, however, any other senders 
using the 98743S1 ©Bpemknpoxom emsD address 
will receive sn industry-standard "no such tucr" 
error message because no additional entries in 
the ASL tabic will be made. 

3 See description for FIG. UB Row 4 shove. 

3 See description for FIG. 11B Row 4 above. 

4 The Web site that received a anmnunicatbo from 
the god-user he* replied by sending an email 
FROM sides@ycwnhoes.com TO: 456789® 
spamkapuxam. This row is the resulting 
insuntiaiion. Because column f in the 
corresponding row in FIG. JlA shows a max 
sender of 1, any other sender that attempts to 
send an email to 45G789@spankBpu.com will 
receive an industry-atnodaid "no such usee" 
error message. 

5 Note that there is ao entry in FK3. 11A bat there 
is no corresponding entry in FIO. 11 B. This is 
because no sender has scat an emaO lo Iho proxy 
address in column t of Iho corresponding row is 
FIO. 11A. 

6 Mole that there is an entry in FIG. 12A but there 
b no corresponding entry in FIG. 11 B. This is 
because no sender km scat an email to the proxy 
address in column a of the corresponding row In 
FIO. 11A. 



[0100] FIG. 12 provides a detailed desert prion of ibe 
instantiation process. M SKPF’ is definod to mean “SkProxy 



• 28 




Dec 01 00 05 ; 24p 



Thomas D. MacBlain 



609 696 0222 



P 



US 2003/0191969 A1 



Preprocessor". Id Step 1201 the SKPP searches for and 
matches the proxy email address (in the “TO: M field) in the 
SKT shown in FIG, HA. Step 1202 extracts the sender's 
email address in to two parts, the “userid”, represented by 
the information to the left of the symbol in an Interact 
standard email address, and the domain, represented by the 
information to the right of the M @" symbol in an Internet 
standard email address. Step 1204 determines if the proxy is 
for an entire domain or for only a specific user email address. 
Step 1205 adds an entry in the ASL table to allow this and 
any further emails from this entire domain to be identified as 
“FRIEND” without further validation. An entire domain 
proxy would be useful if a user wanted the proxy email to 
be used by anyone within that domain; examples might 
include online orders or newsletters where it is acceptable to 
receive email from any address within that domain such as 
ordcr-cDofirmation@arnazon, order-6iatus@am azon.com, 
order-snpport@amaaton.com. Step 1203 adds an entry in the 
ASL table to allow this and any further emails from this 
specific email address only to be identified as “FRIEND” 
without further validation. A specific user address proxy 
may be useful if one wishes gives out ao email address lo a 
specific individual without forcing that individual to go 
through a validation process. In Step 1205, an entry is made 
in the SKIT table shown in FIG. UB and all the fields are 
filled. Step 1207 returns control to Step 1012 in FIG. IOC 
and the proxy processing process continues. 

[0101] Once a P ^xy^maxl ^drcss has been instantiated, 
it can only be used for the specific FROM domain or email 
address that it was instantiated for. For example, if an 
end-user submitted their domain-wide proxy email address 
for the purpose of an online order, and that email address 
was subsequently instantiated, the proxy email address 
cannot be successfully used by a sende r that does not use the 
same domain namo as the ontioe order vendor. 

[0102] By dcfiniiijpbsmaximum amount of senders that 
may use a given proxy adSress, the end-user can effectively 
create “private email "defworks” whereby the proxy email 
address will work for collection of individuals or organiza- 
tions but docs not work for others. 

[0103] Existing standard email configurations as shown in 
FIG. 13A use an email server 1302 to receive email, store 
email in an inbox lo be retrieved by client computer, and to 
transmit email sent by die client computer 1301. The 
improvement in this invention as shown in FIG. 13B allows 
a SpamKapu server lo be easily installed in an existing email 
network &s a hardware network appliance device with mini- 
mal reconfiguration of the existing network and/or addi- 
tional maintenance labor from staff. 

[0104] FIG. 13B illustrates bow the invention would be 
installed so that any incoming email would first pass through 
the processing of the SpamKapu server. Only validated 
FRIEND email would pass through to the (previously) 
existing email server 1302. All existing configuration and 
processing on that existing email server would continue 
unchanged. Outgoing email would go from the client com- 
puter 1301 lo the existing email server 1302 which in-torn 
will use industry-standard relay specifications to pass its 
email to the SpamKapu server 1303 which would copy all 
recipient email addresses to its ASL Rules List as 
“FRIENDS”, then send the email to its intended destination 
server and recipient. This configuration provides a simple 
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and transparent method to both block all incoming spam and 
easily copy the outgoing emaQing addresses into the ASL 
Rules list. 

[0105] FIG. 13C illustrates bow the invention can be| 
installed at an ISF facility lo provide spam protection lo the 
subscriber base. Tbc SpamKapu email firewall 1303 is 
installed to process mail addressed to subscriber accounts 
1305. Subscribers interact with the SpamKapu email fire- 
wall 1303 via the provided Web interfaces and XML inter- 
faces (see FIG. 8). fn this configuration, spam protection can 
be provided to an ISP subscriber base. 

[0106] FIG. 13D illustrates bow tbc invention can be 
installed at a network connectivity providers facility to 
effectively offload spam-related email bandwidth for ISPs or 
corporate installations. All incoming email from the Internet 
1305 is sent to the network provider facility 1304 that 
typically has significant bandwidth capability. All spam- 
related email is rejected by the SpamKapu email firewall 
1303 as described previously. The remaining spam-free 
email 1307 then passed to the ISF or corporate email server 
1302. The end results is the effective reduction of bandwidth 
used to amply transmit spam. 

[0107] FIG. 13E illustrates bow the invention can be 
installed at a wireless telephone service provider facility to 
provide spam protection for wireless subscribers. Most 
carriers provide an Internet email gateway 1308 whereby 
wireless subscribers can send and receive Internet email. 
The spamKapu email firewall 1303 is installed to process 
mail addressed to subscriber accounts 1307. Subscribers 
interact with the SpamKapu email firewall 1303 via tbc 
provided Web interfaces and XML interfaces (see FIG. 8). 
To provide added functionality for wireless phone subscrib- 
ers, an additional communication layer that follows the WAP 
(wireless access protocol) is illustrated to allow subscribers 
lo interact with the SpamKapu firewall using only their 
wireless device. In this configuration, spam protection can 
be provided an wireless subscriber base. 

[0108] The firewall configuration is not intended to 
replace any existing firewall devices operating on the net- 
work. For network configuration purposes, the SpamKapu 
email firewall replaces the existing email server that pro- 
cesses external incoming email and transmits email 
addressed lo external servers. The ideal configuration of the 
SpamKapu firewall is to be considered a hardware compo- 
nent alongside the existing email servers and in conjunction 
with any other existing firewall devices. 

[0109] The optimal commercialization of the SpamKapu 
server will be as a network appliance. This can be packaged 
as a complete hardware and software solution or the soft- 
ware can be installed oo dedicated hardware by. knowledge- 
able technicians. The key envisioned commercial applica- 
tions include A) Commercial ISfc that use the SpamKapu 
technology lo provide spam elimination services to their 
clients. B) Network providers that offer both spam elimina- 
tion and reduced bandwidth usage. 

[0110] FIG. 13F illustrates how SpamKapu can be 
installed oo an existing email server 1311 in a pure software 
configuration. The established Internet email standard pro- 
tocol uses TCP/IP port 25 to send aDd receive email. By 
reconfiguring the existing email server 1311 to look for 
incoming email on Bnotber port, for example 1125, and 
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r transmit email on port 25 and configuring SpamKapu soft- 
ware 1312 to look for inooming mail on porl 25 and send its 
mail through port 1125, the SpamKapu server is properly 
inserted into" the email transmit and receive process. In the 
case of incoming email, it is fifg routed through Spam- 
Kipu's receive process in step 1312 via port 25 and then is 
sent lo the existing email server via port 1125 where the user 
dienl 1301 cm retrieve the email. In the case of outgoing 
mail, the client connects lo SpamKapu’s transmit process 
via port 25 which performs processing as detailed in FIG. 
36, and is then sent via port 1125 to the existing email server 
1311 which in-lum sends the email to its destination over the 
Internet via port 25. The configuration illustrated la FIG* 
13F allows the SpamKapu invention to be installed on 
existing server hardware thereby lowering the overall cost 
L ^ acd maintenance involved with additional hardware. 



[0111] In summary, the present invention provides a spam 
emailrcjcctioo method which analyzes the sender address of 
incoming email and determines whether it is to be rejected 
before being accepted by an eraril-rccemrtg server by 
returning a standard “no such user" error code or redirecting 
it elsewhere. This provides an advantage over existing 
anti-spam filtering systems which aoccpt all email and 
attempts to filter out only those that have sender addresses 
recognized as those of known spammers. The invention 
employs an ASL module to capture authorized sender email 
addresses from the user's outgoing email or other sources in 
order to update the “authorized senders” (ASL) lists. The 
WBM procedure allows senders of rejected email to go to a 
separate website and register os valid senders after passing 
an interaction test that confirms that il is not being done bv 
j mechanical program J rbc SkProxy procedure allows sub- J 
"sensors to use temporary proxy addresses for receiving j 
email expected from unknown sources and instantiates send- / 
cis as authorized upon receiving the expected email to ibe J 
[proxy addresses^ Tbe uoauthonziid-eiJUU lejeulUU duuipu- 
Ttent 01 LixTsy&em can be readily configured as a hardware 
or software appliance used in tandem with a conventional 
email server, email gateway, or firewall to an intranet, or as 
a software extension to an existing firewall system. 



[0112] It is understood that many other modifications and 
variations may be devised given the above description of the 
guiding principles of the invention. It is intended that all 
such modifications and variations be considered as wiibin 
the spirit and scope of this invention, as defined in the 
following claims. 



I claim: 

1. A system for eliminating unauthorized email scot to a 
user on a network comprising; 

(a) an email client for allowing the user to receive email 
fcenl on the network addressed to a unique email 
address of the user, 

(b) an email-receiving server connected between the 
network and the email client for receiving email 
addressed to the unique email address of the user, 

(c) an unauthorized-email rejection component having on 
authorized senders list (ASL) module which maintains 
email addresses of senders authorized to send email to 
the user, wherein (be unauthorized -email rejection 
component is operable with the email- receiving server 



for intercepting and rejecting any unauthorized email 
addressed to the email address of the user. 

2. A system for eliminating unauthorized email sent to a 
user on a network according to claim 1, wherein the unau- 
thorized-email rejection component is positioned in the flow 
of incoming email upstream from the email-receiving server 
such that unauthorized cmafl is ini creep led and prevented 
from reaching the email -receiving server. 

3. A system for eliminating unauthorized email seat to a 
user on a network according to claim I, wherein tbe unau- 
thorized-email rejection component is configured as a hard- 
ware appliance that is positioned in the flaw of incoming 
email physically upstream from the email-receiving server. 

4. A system for eliminating unauthorized email sent to a 
user on a network according to claim 1, wherein tbe unau- 
thorized-email rejection component is configured as a soft- 
ware component operable in tbe flow of incoming email 
logically upstream of the cm ail- receiving server. 

5. A system for eliminating unauthorized email scot to a 
user on a network according to claim 1, further comprising 
an email proxy pre-processing module that allows users to 
designate a destination proxy email address for use by a 
sendor in instances where the email address of an authorized 
sender is not ycl known, examines incoming email and, 
upon recognizing the destination proxy email address of the 
user, accepts tbe email and sends it to the user. 

6. A system for eliminating unauthorized email sent to a 
user on a network according to claim 1, further comprising 
a WBM component for sending a message to a rejected 
sender inviting the sender to be validated as an authorized 
sender. 

7. A system for eliminating unauthorized email sent to a 
user on a network according to claim 6, wherein the WBM 
component specifies a predetermined time period for the 
sender of rejected email to be validated as an authorized 
sender. 

8. A system for eliminating unauthorized email sent to a 
user on a network according to claim 6, wherein tbe WBM 
component is installed on a separate website . that can be 
accessed by a sender of rejected email to be validated as an 
authorized sender. 

9. A system for eliminating unauthorized email seat lo a 
user on a network according to claim 6, wherein tbe WBM 
component requires a sender of rejected email to pass an 
interaction procedure to show that the sender is not a 
mechanical program attempting to automatically validate 
the sender. 

10. A system according to claim 9, wherein the interaction 
procedure includes a display of a graphic image of o word 
or object, and an input for tbe sender to enter in a text word 
i‘d response to the graphic image, whereby the system can 
confirm that tbe interaction procedure is not being per- 
formed by a mechanical program. 

11. A system according to claim 6, wherein once tbe 
sender is confirmed as an authorized sender of email to the 
intended recipient user, tbe WBM component sends an 
appropriate update to the ASL module that allows subse- 
quent emails from the sender to pass through normally. 

12. A system according to claim 1, wherein tbe ASL 
module includes an ASL database for storing ASL lists of 
processing rules and authorized sender addresses for respec- 
tive usees of the system, and a spam processor module for 
processing the ASL rules lists to determine if the sender is 
friend, spammer, or unknown. 
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13. A system according to claim 1, wherein, upon the ASL 
module determining that incoming email has a sender 
address that is not that of an authorized sender, said unau- 
thorized-email rejection component rejects the incoming 
email with an industry standard "no such user'’ error mes- 
sage. 

14. A system according to claim 1, wherein the ASL 
module includes an ASL list manager for analyzing email 
header information including FROM and TO addresses of 
email sent by users to dynamically update Lbe ASL lists of 
authorized senders. 

15. A system according to claim 1, wherein the ASL 
module includes a rules processor for processing authorized 
sender addresses for updating the ASL lists using data from 
an email address source selected from the group of email 
address sources consisting of: received email; sent email; 
user inputs to email service functions on the email client; 
inputs from user browsing of web sites; user desktop orga- 
nizer and other contact lists; and third party address email 
management programs. 

16. A system according to claim 1, wherein the ASL 
module includes a rules processor for processing analysis 
rules for updating the ASL lists using data from an analysis 
source selected from Lbe group of analysis sources consist- 
ing of: user email log analysis; expiration date analysis; 
low/high email volume analysis; fuzzy logic analysis; and 
third party data analysis. 

17. A system according to daun 1, wherein the ASL 
module maintains the ASL lists using a designation of 
sender-address status selected from the group of sender- 
address status designations consisting of; always authorized 
as a friend; authorized as a friend over a dale range; 
authorized as a friend before an expiration date; authorizing 
all email for a given domain name; authorizing all email for 
a domain or any subdomain; always rejected as a spammer; 
rejected as a spammer matching a black list; status relumed 
by executing a 3 rd party email software; and rejected as a 
spammer sent with an error message. 

18. A method for eliminating unauthorized email sent to 
a user on a network comprising the steps o£ 

(a) receiving Incoming email addressed to lbe unique 
email address of the user, 

(b) maintaining an authorized senders list (ASL list) of 
email addresses of external users authorized to scud 
email to the user, 

(c) processing the sender's email address on incoming 
email by comparing it to tho ASL list, and 

(d) rejecting the receipt of incoming email before the 
email can be accepted for delivery to the user if the 
results of processing the ASL list returns with a result 
of “unauthorized sender" by returning an industry 
standard "no such user" error code. 

19. A method for eliminating unauthorized email sent to 
a user on a network comprising the steps o£ 

(a) receiving incoming email addressed to the unique 
email address of the user, 

. (b) maintaining an authorized senders list (ASL list) of 
email addresses, of external users authorized to send 
email to tho user, 

(c) processing the sender's 'email address on incoming 
email by comparing it to the ASL list, and 



(d) rejecting the receipt of incoming email before the 
email can be accepted for delivery to the user if the 
results of processing the ASL lot returns with a result 
of ‘"unauthorized sender", sending a message inviting 
the sender of the rejected email to confirm that the 
sender is an authorized sender of email to the intended 
recipient by passing an interaction procedure to show 
that lbe sender is not a mechanical program attempting 
to automatically validate the sender, and thereupon 
adding the validated sender's email address to the ASL 
list. 

20. A method for eliminating unauthorized email sent to 
a user on a network comprising the steps of: 

(a) receiving incoming email addressed to the unique 
email address of the user, 

(b) maintaining an authorized senders list (ASL list) of 
email addresses of external users authorized to. send 
email to the user, 

(c) processing the sender’s email address on incoming 
email by comparing it to the ASL List, 

(d) rejecting the receipt of incoming email before the 
email can be accepted for delivery to the user if the 
results of processing the ASL list returns with a result 
of “unauthorized sender", and 

(e) allowing a user to designate a destination proxy email 
address for use by a sender in instances where the email 
address of an authorized sender is not yet kuowo, 
wherein if the destination proxy email address is rec- 
ognized on incoming email, the incoming email is • 
accepted and sent to the user. 

21. A method for eliminating unauthorized email sent to 
o user on a network comprising the steps of: 

(a) receiving incoming email addressed to the unique 
email address of the user, 

(b) maintaining an authorized senders list (ASL list) of 
email addresses of external users authorized to send 
email to the user, 

(c) processing the sender’s email address on incoming 
email by comparing it to the ASL list, and 

(d) rejecting the receipt of incoming email before the 
email can be accepted for delivery to the user if tbe 
results of processing the ASL list returns with a result 
of "unauthorized sender", 

wherein the ASL module includes aq ASL list manager for 
analyzing email header information including FROM 
and TO addresses of email sent by users to dynamically 
update the ASL list of authorized senders. 

22. A method for eliminating unauthorized email sent to 
a user on a network comprising the steps of: 

(a) receiving incoming email addressed to tbe unique 
email address of the user, 

(b) maintaining an authorized senders list (ASL list) of 
email addresses Of extcroal users authorized to send 
email to tbe user, 

(c) processing the sender's email address on incoming 
email by comparing it to the ASL lis^ and 
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(d) rejecting tbo receipt of incoming email if the results of 
processing the sender's email address with the ASL list 
returns with a result of “unauthorized sender*, wherein 
the rejection of the incoming email is performed is a 
physical or logical operation before the email can be 
accepted for delivery to the user. 

23. An unauthorized-email rejection component for use 
with an email-receiving server for receiving email sent to a 
user on a network comprising an authorized senders list * 
(ASL) module which maintains an ASL list of email 
addresses of scoders authorized to send email to the user, 
wherein said unauthorized-email rejection component inter- 
cepts and rejects any incoming email addressed to the email 
address of the user if the processing results of the ASL list 
returns with an "unauthorized sender” result, wherein tbo 
unauthorized-email rejection component is a hardware or 
software appliance positioned for operation in the flow of 
incoming email physically or logically upstream from the 
email- receiving server to prevent any unauthorized email 
from reaching the email-receiving server. 

24. An unauthorized-email rejection component for use 
with an email-receiving server for receiving email sent to a 
user on a network comprising an authorized senders )i It .. 
(ASL) module which maintains an ASL list of email' 
addresses of senders authorized to send email to the user, 
wherein said unauthorized-email rejection component inter- 
cepts and rejects any incoming email addressed to the email 
address of the user if the processing results of the ASL list 
returns with an “unauthorized sender” result, wherein the 
ASL module includes ad ASL list manager for analyzing 
email header information including FROM and TO 
addresses of email sent by users to dynamically update the 
ASL lists of authorized senders. 

25. An unauthorized -email rejection component for use 
with an email-receiving server for receiving email sent lo a 
user on a network comprising an authorized senders list 
(ASL) module which maintains an ASL list of email 
addresses of senders authorized to send email to the user, 
wherein said unauthorized-email rejection component inter- 
cepts and rejects any incoming email addressed to the email 
address of the user if the processing results of the ASL list 
returns with an “unauthorized sender" result, and further 
including a proxy address module for allowing a user to 
designate a destination proxy email address for use by a 
sender in instances where i be email address of an au tborized 
sender is not yet known, and if the destination proxy email 
address is used on incoming email, for accepting the incom- 
ing email and sending it to the user. 

26. An unauthorized -email rejection component for elimi- 
nating unauthorized email according to claim 25, wherein 
upon receipt of incoming email using the destination proxy 
address, an entry for the email address of the sender thereof 
is dynamically created in the ASL module as an authorized 
sender. 

27. An unauthorized -email rejection component for elimi- 
nating unauthorized email according to claim 25, wherein 
said unauthorized-email rejection processes the incoming 
email using the destination proxy address according to rules 
that permit email to be aoceptcd from a specific user, 
domain, and/or subdomain represented in the proxy address. 

28. An unauthorized -email rejection component for use 
with an email-receiving server for receiving email sent lo a 
user on a network comprising an authorized senders list 
(ASL) module which main tains an ASL Ksl of email 



addresses of senders authorized to send email to the user, 
wherein said unauthorized-email rejection component inter- 
cepts and rejects any incoming email addressed to the email 
address of the user if the processing results of the ASL list 
returns with an “unauthorized sender" result, and further 
including a redirector module for sending a message inviting 
the sender of the rejected email to confirm that the sender is 
an authorized sender of email to the intended recipient by 
passing an interaction procedure to show that the sender is 
not a mechanical program attempting lo automatically vali- 
date the sender, whereupon the validated sender's email 
address can he added to the ASL list. 

29. An unauthorized-email rejection component for use 
with an email-receiving server for receiving email sent to a 
usej on a network comprising an authorized senders list 
(ASL) module which maintains an ASL list of email 
addresses of senders authorized to send email to the user, 
wherein said unauthorized -email rejection component inter- 
cepts and rejects any incoming email addressed to the email 
address of the user if the processing results of the ASL list 
returns with an “unauthorised sender'* result and returns an 
industry standard “no such user" error code before the email 
can be accepted for delivery to the user. 

30. A system for eliminating unauthorized email sent to a 
user on a network comprisicg; 

(a) an email client for allowing the user to receive email 
sent on the network addressed to a unique cm&fl 
address of the user, 

(b) an email-rccciving server connected between the 
network and the email client for receiving email 
addressed lo the unique email address of the user, 

(c) an unauthorized -email rejection component having an 
authorized scoders list (ASL) module which maintains 
email addresses of senders authorized lo send email to 
the user, wherein the unauthorized-email rejection 
component is operable with the email -receiving server 
for intercepting and rejecting any unauthorized email 
addressed to the email address of the user, 

wherein the unauthorized-email rejection component is 
positioned for operation in the flow of incoming email 
physically or logically upstream before the email- 
receiving server such that unauthorized email is inter- 
cepted and prevented from reaching the email-receiv- 
ing server. 

31. A system for eliminating unauthorized email sent to a 
user on a network comprising: 

(a) an email diem for allowing the user to receive email 
sent on the network addressed to a unique email 
address of the user; 

(b) an email-receiving server connected between the 
network and the email client for reoeiving email 
addressed to the unique email address of the user, 

(c) on unauthorized- email rejection component having an 
authorized senders list (ASL) module which maintains 

• -email addresses of senders authorized to send email to 
thV user, wherein the unauthorized-email rejection 
component is operable with the email-receiving server 
for intercepting and rejecting any unauthorized email 
addressed to the email address of the user, 

wherein the u a authorized-email rejection component is 
positioned for operation in the flow of incoming email 
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physically or logically upstream before the email- 
rccciviog server such lhai unauthorized email is inter- 
cepted and prevented from reaching the email-receiv- 
ing server, and 

wherein, upon the ASL module determining that incoming 
email has a sender address that is not that of an 
authorized sender, said unauthorized-email rejection 
component rejects the incoming email with an industry 
standard 44 no such usee" error message. 

32. A system for eliminating unauthorized email sent to a 
user on a network comprising; 

(a) an email client for allowing the user to receive email 
sent on the network addressed to a unique email 
address of the user, 

(b) an email-receiving server connected between the 
network and the email client for receiving email 
addressed to the unique email address of ibe user, 

. (c) an unauthorized -email rejection component having an 
authorized senders list (ASL) module which maintains 
, email addresses of senders authorized 16 send email to 
the user, wherein ibe unauthorized -email rejection 
component is operable with the cmaQ- receiving server 
for intercepting and rejecting any unauthorized email 
addressed to the email address of ibe user, 

^ wherein the unauthorized-email rejection component is 
positioned for operation in the flow of incoming email 
physically or logically upstream; before the email - 
reCmvinc. server such that unauthorized email is inter- 
cepted and pi evented from reaching the email-receiv- 
ing server, and 

wherein the ASL module includes an ASL list manager for 
analyzing email header information including FROM 
and TO addresses of email scot by users to dy namicall y 
update the ASL list of authorized senders. 

33. A system for efiminating unauthorized email sen! to a 
user on a network comprising; 

(a) on email client for allowing the user to receive email 
sent on the network addressed to a unique email 
address of the user, 

(b) au email-receiving server connected between iho 
network and the email client for receiving email 
addressed to the unique email address of the user, 

(c) an unauthorized-email rejection component having on 
authorized senders list (ASL) module which maintains 
email addresses of seodeis authorized to send email to 
the user, wherein the unauthorized-email rejection 
component is operable with the emafl-receivn ^ server 
for intercepting and rejecting any unauthorized email 
addressed to the email address of the user, 

wherein the unauthorized -email rejection component is 
positioned for operation in the flow of incoming em ail 
physically or logically upstream before the cmail- 
reccjving server such that unauthorized email is inter- 
cepted and prevented from reaching ibe cm oil- receiv- 
ing server, and 

wherein said unauthorized -email rejection component 
includes a redirector module for sending a message 
inviting Iho sender of the rejected email to confirm tbal 



the sender is an authorized sender of email to the 
intended recipient by passing an interaction procedure 
to show that the sender is not a mechanical program 
attempting to automatically validate the sender. 

34. A system for chmi rating unauthorized email sent to a 
user on a network comprising: 

(a) an email client for allowing the user to receive email 
sent on the network addressed to a unique email 
address of the user, 

(b) an email-receiving server connected between the 
network and the email client for receiving email 
addressed to the unique email address of the user, 

(c) an unauthorized -email rejection component having an 
authorized seudors list (ASL) module which maintains 
email addresses of senders authorized to send email to 
the user, wherein the unauthorized-email rejection 
component is operable with the email-receiving server 
for intercepting and rejecting any unauthorized email 
addressed to the email address of the user, 

wherein said system includes a proxy address module for 
allowing a user to designate a destination proxy email 
address for use by a sender in Instances where the email 
address of an authorized sender is not yet known, and 
if the destination proxy email address is used on 
incoming email, said unauthorized -email rejection 
component accepts the incoming email and sends it to 
the user. 

35. A system for eliminating unauthorized email sent to a 
user on a network comprising: 

(a) in email client for allowing the user to receive email 
sent on the network addressed to a unique email 
address of the user, 

(b) an cm ail -receiving server connected between tbe 
network and the email client for receiving email 
addressed to the unique email address of the user, 

(c) an unauthorized- email rejection component having in 
authorized senders list (ASL) module which maintains 
email addresses of senders authorized to send email to 
die user, wherein the unauthorized-email rejection 
component is operable with the email-receiving server 
for intercepting and rejecting any unauthorized email 
addressed to the ©mail address of the user, 

wherein said unauthorized-email rejection component 
includes a redirector module for sending a message 
inviting the sender of the rejected email to confirm that 
the sender is an authorized sendee of email to the 
intended recipient by passing an interaction procedure 
to show that the sender is not a mechanical program 
al tempting to automatically validate the sender, 

wherein tbe interaction procedure includes a display of a 
graphic image of a word or object, and a request to the 
sender to enter a text word in response to the graphic 
image, whereby the system can confirm that the inter- 
action procedure is oot being performed by a mechani- 
cal program, and thereupon ldd the validated sender's 
email address to tbe ASL list. 
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Specification for SpamKapu 
Copyright CyberCom, Inc., 1999, all rights reserved. 
Reproduction or copying of this material or its use In the 
creation of derivative works without the express permission 
of CyberCom, is a violation of federal law and may result in 

civil or criminal penalties. 

(a) Application transmittal form. 

(b) Fee transmittal form. 

(c) Title of the Invention. 

■ SpamKapu " Software to eliminate unauthorized receipt of 
electronic mall (spam) 

(d) Cross Reference to related applications (if any). 

Internet SMTP, POP3, and related standards 

(e) Statement of federally sponsored research/development (if 
any). 

none 

(f) Reference to a microfiche appendix (if any). 

none 

(g) Background of the Invention. 

Not sure here. 

(h) Brief Summary of the Invention. 

Most, If not all, of the current software to control spam is based 
on Identifying lists of spam sources or senders and filtering email 
based on those lists. This technology Is only aa good as the 
Identifying Ust and cannot guarantee that the user wBl not receive 
spam. Today’s spam control software assumes all email Is 
authorized an attempts to filter out unauthorized email. 

Because today’s spam filtering technologies are based on fists of 
known spam sources, It Is impossible for them to filter email that 
comes from non-SPAMMERs that is still undeslred by the user. 

For Instance, one may have disclosed their email address at a 
Web site which now used by Individuals that are sending email to 
the user. These Individuals will never appear of spam lists 

unauthorized and 

must be compared against an "authorized senders " Ust In order to 
bo acceptable to the user. This filters not only spamming 
sources, but any sender which the user deems as unauthorized. 
This creates an Inherently powerful and 100 % private email 

solution. 

SpamKapu Intelligently formulates the "authorized senders" list 
based on analysis of the usets email usage (such as sent email) 
and a gathering of key data such as their known contacts and 
associates. The authorized senders list may also be easily 
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manipulated by the user at any time to add or remove authorized 
senders. 



To summarize: SpamKapu effectively blocks 100 % of 
unauthorized email to the user. It Is based on the Idea that If you 
did not send someone an email, they are not authorized to send 
you emaU. 

(!) Brief description of the several views of the drawing (if 
any). 

(J) Detailed Description of the Invention. 

SpamKapu Is formed of several key modules and definitions: 
SUBSCRIBER: the person that using SpamKapu. 

FRIEND: an email-sending source that is authorized to send 
email to the SUBSCRIBER. 

SPAMMER: an email-sending source using manual or highly 
mechanized means to send one or more emails through the 
Internet that is not authorized to send emal to the 
SUBSCRIBER. 

CONTACT: an email-sending source that is a human being 
attempting to reach the SUBSCRIBER fora legitimate cause. 
SUSPECT : an email sending source that has not yet been 
Identified as either a SPAMMER or CONTACT. 

ASL Manager 

Software designed to populate the ASL from a variety 
of methods: 

Contact lists of the user indicating Friends. 

Continual analysis of sent mail logs which may 
expose additional Friends. 

Standard file formate (f.e. comma-delimited) which 
would allow subscribers to easily update their ASLs. 
Spam Processor (SP) 

Decides whether an email address Is FRIEND, or 
SPAMMER by executing rules on the SPDB In 

conjunction with the ASL. 

Returns this result along with any message to 

Include in the error response to the REDIRECTOR. 
Uses Industry standard PERL programming syntax 
and Incorporates as PERL Interpreter to execute 
rules. 

Spam Processing database (SPDB) of which a unique copy 
exists (breach SUBSCRIBER, composed of several tables: 
Authorized sender list (ASL), containing 

An email address or matching pattern for an email address 
Default: exact match 



A specific email address 

john@company.com 
UNIX Standard wildcard matching 




♦jmoDsoftxom Le. anything from 

‘Microsoftccm” 

*03100308*: anything with nricroeoft in 
it 

•.mil: any email ffrm the military 
Matching say known “blackhole list” by using a 
% BLACKHOLE % aymbol. 

A conditional and parameters to execute if the match is true 
An action and parameters to perform if the conditional Is 
true. 

A parameter used by the secondary action 
The last date the SUBSCRIBER sent emai] to this address 
The last date this address sent email to the SUBSCRIBER 
Date the record was created 

Example list of condttionale to be used by the SPAM 
PROCESSOR, e.g: 

expiration dates. 

A given address until 2/12/2004 
Date ranges 

A given address front 4/1/2004 to 5/2/2004 
Specific recurring times 

first week of every month but no other time. 
c.g Ecwdcaer@maga7ine.com 
acceptable during 1“ week of each 

pyrp fh , 

A link to external software designed to allow for additional 
user-defined criteria 

This allows lor 3* party applications. 

Example list of different secondary actions to take 
Send a given message in the error response. 

Send a given message as an email. 

Open a file and email its contents 

Open a file and send its contents as an error rcpoose. 

Set the sender's status to SPAMMER or FRIEND 
Give SMTP default error message 
Link and execute external software designed to alow tor 
additional user-defined actions 

This allows for 3** party applications. 

List of messages that may be invoked by a given 
secondary action 

Standard “error” 

Custom with variable substitution in the message body, e.g: 
%nseraame% is substituted with the sender's 
email address 

%snbid% is the ID code of the subscriber 
%date% is today’s date 

“hello %usemame% you have been identified as spam, go to 
hMD^/www.spamkaDU.com/subscribw%subidS4 and if 
you're really human well let you in. 
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Custom text “All email addresses from America Online are 
unconditionally rejected” 

Authorized Sender mailbox (ASM) 

An electronic mailbox confirming to popular Internet 
standards (as of this writing, POPS & IMAP4) that 

contains email sent from FRIENDS. 

SpamKapu email address (SKE) 

An Internet SMTP -complied email address provided 

by spamkapu that la unique to the SUBSCRIBER. 

Redirector 

Software that intercepts incoming email sent to the 
SKE, routes ft's sender’s email address to the SP for 

validation (FRIEND, or SPAMMER) 

If FRIEND, the email Is directed to the ASM. 

If SPAMMER, the SPAMMER is given an error 
message similar to one If the user didn't exist along 
with Information on how to access the 
SUBSCRIBER’S WBM should further communication 

Web-bafe^ln^enger (WBM) 

A Web site that designed to determine if a SUSPECT 
Is either a SPAMMER or a CONTACT. 

An online form would be presented to the SUSPECT 
to allow entry of the intended message to the 
SUBSCRIBER. 

This form would operate In such a way that only a 
human SUSPECT would be able to properly execute 
the form. 

A unique web page with a random word would be generated 
The SUSPECT would be prompted to enter the word. 

If the word matched, the form would be considered 
“operated by a human” and the SUSPECT is now deemed as 
a CONTACT 

If validated as a CONTACT, the message In the form 
along with the CONTACT’S email address would be 
sent as a special email to the SUBSCRIBER’S ASM. 
The subject line of the email would contain the word 
“contact:” so it could easily be filtered or be subject 
to special processing by an industry standard email 

fttlP&UBSCRIBER would have the opportunity to 
read the email, knowing that at least It was sent by a 

CONTACT. 

ASL manager 

Software that Intercepts all sent email from the 
SUBSCRIBER and copies the recipients along with 
other Information Into the ASL 
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The ASL manager may work on either a dynamic (as 
emails are sent) or batch (analyze logs or other data 
sourcos). 

The ASL works In conjunction with the UMM 
SMTP manager 

Software that provides a SUBSCRIBER with an SKE 
and Interfaces with other Internet SMTP standard 
functions such as: 

Sending email FROM or TO the subscriber through die ASL 
manager. 

For example, the SMTP manager may interface with the 
subscribers "official" or known corporate address to 
eliminate spam sent to the corporate email system. 

User maintenance modules (UMM) 

A set of software utilities that allow the SUBSCRIBER 
to maintain personal settings and the ASL Examples 
include: 

Default expiration settings. 

Bulk-loading of friends into the ASL 
Sea rch/add/ed it/delete ASL entries 
Handling of mail once sent to PSM (l.e. create a 
predefined response to the spammer) 

Outright rejection Of email, disallowing it to even get 
to the PSM. 

Preview/Delete items from the PSM 
Other features of benefit to subscribers 
SpamKapu may bo packaged In a variety of ways 

As an online service (i.e. Web site) lhat allows users to 
subscribe and realize the benefits of spam-free email services. 

As a server-side software package. By installing SpamKapu at 
the server level, any/all users with a valid account on the server 
can receive the benefits of spam-free email. This is an idea 
solution for ISPs and/or larger organizations with their own 
server resources. 

As a client-side software package. SpamKapu can install on 
popular email clients such as Outlook and provide near-identical 
functionality. This is an idea situation where the user's server 
does not have SpamKapu installed 
Operation of the Invention 

As a server-side software package or online service 

SUBSCRIBERS are added to SpamKapu system. 

Each SUBSCRIBER is provided with a PSM, ASM, 
and UMM and an SKE. 

The SUBSCRIBER changes appropriate setting on 
their email software to accomplish the following: 

Use current Internet standards (currently POP3 or IMAP4) to 
retrieve mail from both the PSM and ASM 
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Redirect email sort to their current email address to their 
SKB instead OR set the email reply -to address to their SKE. 
Use the SMTP manager to handle flic sending of all email 

Any email sent to the SKE is processed by the 
redirector as described above. 

Any email sent by the SUBSCRIBER through the ASL 
manager (via the SMTP manager) and processed as 
described above. 

The user can retrieve email from the ASM at any time 

using Internet standards (currently POP3 or IMAP4). 
The user can retrieve email from tne PSM at any time 
using Internet standards (currently POP3 or IMAP4) 
user other software that can delete, further filter, or 

altaiether discard the contents. 

SUBSCRIBERS may Interact with the UMM at any 

time. 

Use of SMTP-standard email error response codes as 
a matter of rejecting user-specific spam 

This is being used today, but only where a given email 
server is rejecting ALL email from a given NETWORK. 
This claim is against SPECIFIC email directed to a 
SUBSCRIBER that is identified to have originated from a A 
SPAMMER. 

As a client-side software package on an Outlook 98 or greater 
client 

After Installation, a folder labeled "PSM" will be 
created. 

Users may interact with the a client-side installation 
of the UMM at any time. 

ASM will be sent to the standard "inbox” folder and 
PSM will be sent to the "PSM” folder. 

Other operations are similar to the server-side 
package or online service described above. 

(k) Claim or claims. 

Any software which analyses the user's personal email usage 
patterns to create an ASL or equivalent and In-tum uses this ASL 
to make decisions on how to process Incoming email. 

Analysis of sent email and received to determine and refine the 

ASL. 

Analysis and rejection of SPAM at the lowest (earliest) possible 
level In the mall transmission protocol such that SPAMMERS 
receive error messages Indicating the user doesn’t even exist 
SUBSCRIBER never even processes or downloads email. 

Analysis of contact databases to determine and refine the ASL 
Analysis of email logs (both sent and received) to determine and 
refine the ASL 

Methods to only allow humans to access the WBM to send 
messages to the SUBSCRIBER. 




Methods for 3 rt party software to Interface with SPAMKAPUto 
broaden the scope and functionality of determining If email Is 
SPAM or not, for example: 

Analysis against 3™ party databases such as the Better 
Business Bureau 

Methods for 3** party software to Interface with SPAMKAPU to 
broaden the scope and functionality of the various types of 
actions that can be taken on SPAM. 

Methods for 3* party software to Interface with SPAMKAPU to 
broaden the scope and functionality of analysing power 
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(l) Abstract of the disclosure. 

(m) Drawings (If any). 

(n) Executed oath or declaration. 

(o) Sequence listing (if any). 

(p) Plant Color Coding Sheet (applicable in plant patent 
applications). 

Other 

dtUflow of overs!! system 
ssnmr-bsssdsrMtoctws o f system 
c itent-bsssd s r ch fteeten oi system 

list of other Idmsndusss of ths system indvsrfsncss to do the mom thing (o&nrttmn 
spsmmfag) 

references to other technology used 
RFC 821 
SMTP email 
PERL 
Sendmail 

RearTime Blackhole List (www.matabuse.oig) 
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or not to attempt to be 
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"SpamKapu" detailed operation of SPAM PROCESSOR DATABASE 

Confidential Information. 

This document Is the property of CyberCom, tnc. and sent under attomey-cfent prrytedge. 



Using FROM email address 
supplied, loop through each 
line of the A3L untfl there is a 
pattern match in this field 



Once there is a 1 
pattern match, 
execute the condition 
based on the code In 
this field i 







Execute' 



|iphn@homo.com 
•laaolcoml 



payemj condition 



mBmOatitinpi 1 



sales@a|na mm 




Jf the condition returns TRUE, 
execute the action based on 
the code In this field and exit. 
If condWon returns FALSE, 
continue looping through 
each email pattern 



ASL Table (example) 



action if true 



flT.'r' ElMMEBE 



acttverar ge \ 

(2/6/200 , 

8/5/2004 I friend 



before 
(12/1/2003) 



always 



blackholef) 



actfverange 
(3/14/*. 3/20HI 



always 



Action- 



Ifrtend 



email (SPAMMER, 
noaol.ferf'il 



emalltmother (SPAMMER, 
blacklist txt, 
abuse@%domain% 
%SENDER%, 
admln@spamkapu.com) 



|frtend 



enrormsgefspammer, 
oontacttxt 5S0) 



Comment) 

[this is my mom so she’s always a frtendT 



l*m working with this businessperson only fron\ 
Feb 5 to June 6 



After 12/1/2003, 1 do not wart messages from 
this address 



email we get from aol gets send back with an 
explanation! 



run a 3rd party software, mark aa a spammer, 
send a standard massage to the system's 
administrator, and mark it as coming from 
8Damkapu'8 administrator 



my birthday tolls on 3/17, so from 3/14 to 3/20, 
111 let anyone pass through to wish me a 
happy birthdav.1 



mark as spafnmer, send the "you might be a 
contact" message, return "No such user errors . 
code 



condition | syntax) 



0S5TimiE3H3 



acttveranoe 



runcoda 



btackhota 



before 



acthrerange (low ! 
[date, high date! 



Condition Table (example) 

description codej 

return true alwavsl 



runcode(fiJename) 



blackholef) 



before(date) 






true if today Is within a ranoej 



runs long and lengthy code 
program 



3id party software to check 
against a blackhole Bat 



true If today fa teas than date Iretumftrua) 



action k| 



syntax! 



email 



enormsa 



external 



emaflitn 

fspammert 



Action Table 

desert 



if today >= %1 and today | 
<°=%2 then retum/treetl 



execffPe.pl) 



execfblackholaexB) 



if today <«%1 then 



emaitf ktent hie) 



[dent, file, 



return parml as Identifier, get 2nd parameter as a 
[filename, translate and return it as the error code I 



exacffile)! 



emalitmottier (Went, 
filename, to. from) 



retumfSPAMMERY 



retumfSPAMMER) 



^example) 



return parml as identifier, gat 2nd parameter as a 
filename, translate and email It 



execute 2nd parameter as an external 3rd party 
software pa ckage and return Its result as the j 



return parml as identifier, get 2nd parameter es 
filen ame o f message text, send It as an email to 4th 
Parameter, and use 3rd parameter as FROM 



return value as FRIEND, no parms needed! 



return value as SPAMMER, no parms needed 








"SpamKapu" detailed operation of ASL Manager 

Confidential Information. 

This document is the property of CyberCom, toe. and sent under attomey-cfent priviedgo. 




The ASL Manager also 
rune task* one 
scheduled bask for 

analysis and 
maintenance functors. 
This aJ) 0 M« a very rich 
ranrfnation of the 
SUBSCRH3B7SASL 
database and mail tog to 
oonttauafiyrafinethe 
database accuracy and 
relevance. 



The system's 
archtectire allows for 
easy Integration of 3rd 
party soMfon* so that 
SpemKapu cen hemess 
the odbctfve power of 
the industry to 
continually eodsnd and 
Improve to feature set 



The uj&n ats reso rtof fob 
architecture Is to create 
e wary richly detafed 
ASL database which 
goes b eyond total 
efcmtostion of spam by 
continually reflecting the 
arrant needs of the 
SUSSCRBB*c*nffrtfc 
use eternal 
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. "SpamKapu" detailed operation of REDIRECTOR 



Typical operation of SMTP "send email” process 



Requeat Connection 



Accept 

Co nn ection 



loop and sand next 
redpientemafl address U. 



+\ oo nfif T nfrte i y afaity to 
prooass re cfo ie n t 




Typically. the standard 
conf r maiton p aitottned Is rtnpty 
based on whether or not the 
user exists or whether or not 
the SMTP receiver has the 
authority to prooeee emafl for 
user. Them Very Bttte to no 
cKParngc pcfiwrnoo* 



Confidential Information. 

This document is the 
property of CybeiCom, Inc. 
and sent under attorney- 
client priviiedge. 



Send message body 
•nd mart and of 



send message to one or 
moreredptenta . 



At fob stage, users are going to 
- get this amaQ In Ihelr standard 
Inbox 



tn 

[Spam Kapu-modifled operation of RECEIVER-SMTP 

process, known as the REDIRECTOR 



I Spam Processor fes 



Request Connection 



Accept 

Canaction 



Store *FROir settees 
for later use. 




At this level we are doing 
exactiy what a standard 8MTP 
receiver would doc either reject 
or accept a given recipient 
address. 



loop and send next 
redptant emafl address 




perform SMTP ndustry- 




4 


r 


i 3 , 

iwmol roioHln 


standard confirmation. 


^ — " — ' 



novroal acceptance.. 



Send emal address of 

FRCMandHBOHB'ir 




Return benflfcattan as 
FRBsdorSPAM^ate 




eno revest nernscaoon 
from spam processor 


soccmpanytng error 
message 


s. 



FWB® $pwum 



embed the error message 
passed from the SPAM _ 
PROCESSOR 



Conflrm 




Reject 


ability to 




abitty to 


process 




procese 


recipient 




redptont 


ernafl 




emal 




If a recipient would hove "normally" 
been accepted, foe SpamKapu 
p nxeee then ta kes over 



Tt . a | a • — _ 

uptanoa m more 
detail elsewhere 



At this tavei, SpamKapu has 
reoog ntoed the aendsr as either 
SRflMMWorFRea ffFRENQ 
then redptant (GUB5CRffia*») 
emafl eddnssa b ounffamod as 



menage to returned. The content 
of the error message provides 
tnebuettens to the user on how to 
cess the VVBMond esttbfeh 
I thBnBoheeneFRIS'O. 



Send meeeage body 
and mark end oT 
message 



send mosswgn to 
redptento Identityng tNe 
sender as FRIEND 
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SYSTEM FOR EL] 






AT1WG UNAUT HORIZED ELECTRONIC MAIL 



This U.S. patent application claims the priority of U.S. Provisional Application 
60/130,025, filed on September 1, 1999, entitled "Unwanted Email Filtering System", and U.S. 
Provisional Application 60/180,937, filed on February 8, 2000, entitled 'Unwanted Email Filtering 
System”, both by die same inventor. 



FIELD OF THE INVENTION 

This invention relates to a system for eliminating unwanted email, and particularly to 

one in which all email must be recognized as sent by an authorized sender in order to be accepted. 

/ 

BACKGROUND OF THE INVENTION 

Unwanted or unauthorized is a significant bane for users on worldwide 
networks, such as the current public Internet Once a person's email address becomes known in a 
network system, it can easily be replicated in computerized lists and passed on electronically to an 
number of parties who have not been authorized or invited to send email to the usct. A 
user's electronic mailbox can become inundated with such unautho rized email. Unauthorized or 
unwanted email is referred to genetically in the industry by the term "spam", although the term is 
not intended to be associated with or to disparage the popular canned meat product sold under the 
trademark "Spam" by Hormel Corp. The user may have an email address with a commercial 
information service provider (BP) service which limits the amount of email flat can be accepted 
and/or stored or which charges the user by the volume received. The user may also waste a 
si gnifican t amount of time opening and reviewing such unwanted email Unauthorized email may 
also be sent by unscrupulous persons who may enclose a virus or noxious software agent in the 




wngii which can infect the user's computer system, or which can be used as an unauthorized point of 
entry into a local network system that handles the user's email. 
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Most, if not all, of the current software to control the receipt of spam is based upon 
die use of identifying lists of known spam sources or senders ("spammers"). Such conventional 
spam control software functions on the basis of receiving all email as authorized unless a sender is 
identified as being on the exclusion list and die email can be filtered out This approach is only as 
good as the identifying list and cannot guarantee that the user will not receive spam. Spammer lists 
require frequent u pdating and must be distributed in a timely mann e r to all subscribers to the spam 
control software or service. Sophisticated spammers frequently change their source Internet 
a nd can defeat attempts to keep exclusion lists current They can also route the unwanted 
«maii through the Internet servers of other parties so as to disguise the source of the emails through 
innocuous or popularly recognized names. A user's email address may also become known to large 
numbers of individuals in public pha* rooms or on public bulletin boards. Unwanted email sent by 
individuals are not trucked on spammer lists, because the sending of email by individuals is 
technically not spamming. 

SUMMARY OF THE INVENTION 

Accordingly, it is a principal object of the present invention to provide a spam 
control system that cannot be defeated by spammers who frequently change their source addresses 
or themselv es by routing through other servers, or by individuals who send email 

Hint are not invited or authorized by the user. It is a particular object of the invention that the . 
system of die invention reject all entail as unauthorized unless the sender is recognized as being on 
the user's acceptance list 



In accordance with the present invention, a system for eliminating unauthorized 
email sent to a user on a network comprises: 
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(a) an «mail client for. allowing the user to receive email sent on the network 
addressed to a unique email address of the user, 

(b) an email-receiving server connected between the network and the email client 
for receiving addressed to the unique email address of die user, said email-receiving server 
having an authorized senders Hat (ASL) module which maintains an ASL list of e ma i l addresses of 
external users authorized to send email to the user, and 

(c) an email rejection module operable with die ASL module for rejecting die 
receipt of email sent to the email address of die user if the email address ofthe sender is not me that 
is maintained on the ASL list for the user. 

fin a preferred embodiment, die system's ASL module in c ludes an ASL database for 
gfftring ASL lists of authorized sender addresses for respective subscribers of the system, a spam 
pjocygsor module for checking the ASL lists for matches, and an ASL manag er for clearing, 
maintaining , and updating the ASL lists. A redirector module rejects email i£ upon se n d in g a 
request for validation to the spam processor module, the sender’s address does not match any 
ayti.nTiT^t sender address found on the ASL list. Email rejected by the redirector module is 
redirected to a web-based messaging (WBM) module which sends a message notifying the solder to 
confirm that the sender is a legitimate sender of email to the intended recipient If the sender logs 
on to confirm their status, the WBM module executes on interaction procedure which can only be 
performed by a human, in order to ensure that die confi rma t i on procedure is not pwfbnned by a 
mechanical pr o gram . The ASL manager m aintains the ASL lists based upon sender address data 
roilpcted from various sources and analyses of various email usage factors, including sent email, 
received e mail, contact lists maintaine d by the user, user preference inputs, thud party programs, etc. 

The -invention also encompasses associated methods of performing the above 
functions, as well as related software Components which enable these functions to be performed. 

Other objects, features, and advantages of the present invention will be described in 
further detail below, with reference to the following drawings: 




BRIEF DESCRIPTION OF DRAWINGS 



FIG. 1A is a block diagram illustrating a standard Internet email system using the 
conv entional method fin filtering email from spammers (Prior Art), as compared to FIG. IB which 
shows a conceptual overview of a system in accordance with the present invention. 
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FIG. 2 is a process flow diagram for a preferred embodiment of the anti-spam 
System of die present invention. 

FIG. 3A is a block diagram illustrating a standard SMTP send email process (Prior 
Art), as compared to FIG. 3B which shows a modified send email process, used in the present 
invention. 

FIG. 4A is a block diagram illustrating a standard SMTP receive email process 
(Prior Art), as compared to FIG. 4B which shows a modified receive email process used in die 
present invention. 



FIG. 5 is a process flow diagram illustrating the operation of an anti-spam 
processing routine in the preferred embodiment of the invention. 



FIG. 6 is a process flow diagram illustrating die detailed operation of a Web-Based 
Messenger (WBM) routine for handling email initially rejected by die anti-spam control. 

FIG. 7A is a block diagram illustrating a standard SMTP sead-reedve email 
handling process (Prior Art), as compared to FIG. 7B which shows a modified Redirector process 
for ha ndling received email. 
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FIG. 8 is a schematic diagram illustrating the structure and operation of the ASL 
Manager in the pr eferred embodiment of the spam control system. 

FIG. 9 illustrates a detailed implementation of examples of processing of email 
send/receiYe and user contact data into specific forms of actions taken by the ASL Manager. 



DETAILED DESCRIPTION OF INVENTION 

In contrast to the known approaches of existing spam control methods of accepting 
all p»«il unless listed on an exclusion list as unauthorized, the fundamental principle of tho present 
invention is to reject all email listed mi an inclusion list as authorized. In this manner, it is 
possible to filter out email that comes from unrecognized spammers as well as individuals who send 
pt nnj l that is uninvited by the user. Unlike the known email filtering systems, the present invention 
does not attempt to filter out the unwanted email after it has been accepted. Rather, it outright 
rejects Ore email at the earliest entry level. Thus, the invention operates on the premise that all 
email will be treated as unauthorized the se nder is found to be on an "authorized senders" list 
in order to be accepted by the user. This provides an inherently powerful and 100% effective spam 
control solution in an environment where spammers can instantaneously cha n ge their source 
address or apparent identity and individuals in public areas can obtain email addresses of other users 
and send them unwanted email. 

The following is a detailed description of pne preferred embodiment of a system for 
implementing the invention concept In this embodiment, the spam control system intelligently 
formulates the "authorized solders" list based upon an ongoing analysis of the user's email usage, 
20 such as to whom and with what frequency sent email is addressed to other users, and through the 
gathering of high-level user contact data, such as a user's known contacts and associates identified 
on other lists or files maintained by the user which indicate persons considered as authorized. The 
"authorized senders” list may also be updated and manipulated by the user at any time to add or 



(3 5 

O 

cn 

mrn 

(0 

(0 

S3 

m 

•mm 

. 10 
» 

(0 

ru 

in 

(3 

(3 



- 5 - 




remove « ^thnri>»H senders. While this specific implementation is used, and certain components are 
provided and configured to be inte rop erable in die described ways, it is to be understood that die 
lull scope of the invention is deemed to encompass many other suitable modifications and 
variations to the describod guiding principles of the invention. 
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FIG. 1A is a block diagram of a standard email system for sending and receiving 
email on die Internet and is used to explain die conventional method for filtering out e m a il from 
spammers. The system follows a standard industry protocol for handlin g email on the Internet, 
referred to as SMTP. Users typically subscribe with a chosen ISP for Internet access and related 
services, m«i"<img email services. The users access the internet through the ISP using a dialup or 
high-speed line connection and a standard browser. The browser includes or functions with a 
standard email client 101, such as die Oudook ™ email client distributed by Microsoft Corp., 
headquartered in' Bellevue, Washington, or the Netscape <n( email client used by AOL/Netscape, 
headq uartered in Fairfax, Virginia. The ISP operates at a website address corresponding to its 
Himuin nam e which is addressable by users on the Interact The ISP's service functions sre 
performed for a large number of subscribers through one or more servers. Typically, an email 
server 102 is used to handle the email service functions. Email sent to the ISP from die Internet is 
received at SMTP Server 102b, where various administrative functions are performed, such as 
^Hriring whether die addressee is an authorized subscriber of die ISP, then die email is placed in a 
storage space reserved for that user, referred to as Inbox 102a. When users connect to the ISP, they 
can retrieve their email and store it with their own email client (on their own computer). Users can 
send email by composing it locally at their email client, then uploading it to the SMTP Server 102b 
at the ISP, which then routes it to the recipient's email address on the Internet 



25 Conventional anti-spam control can be implemented with the SMTP Server and/or at 

the "mail client Many ISPs implement an exclusion list of known spammers at the SMTP Server. 
In addition, they commonly allow a user to filter out unwanted email from certain senders known to 
the user. For example, the user’s email client may have a filtering function dial allows the user to 
input unwanted sender email addresses to the SMTP Server so that email received by the SMTP 
30 Server can be filtered out before being put into the user’s Inbox. Further, independent software 
vendors sell sophisticated email handling programs that work with the user’s email client For 
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examp le, some handling program have functions for categorizing received email into topical file 
folders, and email from unrecognized senders may be put into a "Miscellaneous" or "Unrecognized" 
file folder. 
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5 In FIG. IB, a conceptual overview, of a system in accordance with foe present 

invention U shown. As before, the standard email client 101 is connected to an email server 104 for 
grading and receiving email to and from the Internet via SMTP Server 104b and Inbox 104a. 
However, in this modified email server 104, an Authorized Sender List (ASL) Manager captures 
Recipient email addresses from email sent by the use, as shown at block 105, and also captures 
10 g wf*T pmnii addresses from email sent to foe user, as shown at block 106. The ASL Manager 
analyzes foe captured sender email addresses and recipient email addresses and employs certain pre- 
defined rales (described in farther detail below) to add or remove email addresses from foe 
"authorized senders" Hst, referred to as foe ASL List or Database. The ASL List is used by foe 
SMTP Server 104b to accept only email from Benders on foe ASL List and place foe accepted email 
15 in foe user's Inbox 104a, while rejecting all other email as "unauthorized", as indicated at block 107. 

Referring to FIG. 2, the process flow for the operational steps of foe anti-spam 
system of foe present invention wifi now be described. Certain tenns used in the description are 
defined below: 

20 

SPAMKAPU: An example of the spam control system of the invention. 

SUBSCRIBER: A person subscribing to an ISP email service that is u sing the spam control system 
of the invention. 

FRIEND: An email-sending source that is authorized by foe spam control system to send email to 
25 foe SUBSCRIBER. 

SPAMMER: An email-sending source that is not authorized to send email to foe SUBSCRIBER, 
which is commonly understood to he an unknown or unauthorized party that is vising a manual or 
computerized list jailing program to send large volumes of emails repetitively through foe 
Internet. 
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CONTACT: An email -sending source that has been identified by die system as legitimate 
correspondent of die SUBSCRIBER is authorized by the system to send email to the 
SUBSCRIBER. 

SUSPECT: An email source dial has not yet been identified as either a SPAMMER or a 

CONTACT. 



Fmail sent from the Internet (103) is sent to the email address of the ISP for die 
SUBSCRIBER, referred to in block 201 as the SpamKapu Email Address (SKB). Received email 
must first pass through the Redirector 202. The Redirector 202 sends a request for validation for 
the email fiom the Spam Processor 203 which maintains the Spam Processing Database (SPDB) 
203a, including the Authorized Senders list (ASL) 203b. The SPDB Database and ASL List are 
die heart of SPAMKAPU, as they contain the lists of persons authorized to send email to the 
respective SUBSCRIBERS of die system. The Spam Processor 203 sends a response, either that the 
gender's addre ss on die email is not authorized on the ASL List, i.c., is a SPAMMER, or is 
<m the ASL List, Le., is a FRIEND. If the response fe that it is a SPAMMER, the 
Redirector 202 rejects the email, as shown at block 204, such as by Bending a standard error 
message to the sending server that die user as addressed does not exist 



As a refinement to the system, a Web-Based Messenger (WBM) process at block 
205 may be set up to provide a corrective procedure in die event that the rejected email is from 
someone not authorized but not listed permanently on the ASL list as a SPAMMER. The 
lms nt^ori r^ d emai l may actually be from a person who has not beat previously processed in die 
anti-spam system but who has a legitimate reason to reach the SUBSCRIBER. The WBM process 
205 is set up as part of the spam control system to which the rejected email is redirected. Upon 
receipt of the redirected email, the WBM process stores it in the WBM database, assi g nin g the 
email a unique ID code and also an expiration date. The WBM processthen sends an error response 
email to the email sender, who is now treated as a SUSPECT. For example, the error message may 
read: 

"An email sent by you to SUBSCRIBER’S address was redirected to this site 
as being sent fiom an unrecognized sender address which may be a source of spam 
emai l. If you would like to confirm yourself as a person with legitimate reason to 




reach Oxe SUBSCRIBER, please visit die WBM site (or sold a reply email) and; 
confirm your status as a CONTACT." 

The WBM may have a separate web site address for interactions with SUSPECTS, 
5 • or it may be set up to receive and recognize email responses from SUSPECTS. When a SUSPECT 
receives the error response email, if they are a legitimate CONTACT for the SUBSCRIBER, they 
piny elect to go to fixe WBM site or send a reply onail in order to confirm their status as a legitimate 
CONTACT. If done before the expiration date, the WBM process will add a special codeword such 
as "contact:" to the subject line of the redirected email, as shown at block 206, and re-route the 
10 email to the Authorized Sender Mailbox (ASM) 209. The sender address for email re-directed 
through this process is also stored (as indicated by die dashed line to block 210) and logged for 
further analysis by the ASL Manager 211, to determine if the status of the SUSPECT should be 
£3 upgraded to FRIEND and added to the ASL 203b. If the SUSPECT does not respond, this feet is 
also sent to die ASL Manager for further analysis. The extra confirmation step effectively 
jj |5 eliminates SPAMMERS since Oiey use automated programs to send out batch email and typically 
(Q will not take human response time to log on to the WBM site or send a reply email to confirm their 

vD 

JZ legitimate status. 

U 

C3 

CQ If die Spam Processor sends a validation response that the sender is a FRIEND, thai 

20 the Redirector 202 passes the email to die SMTP Receive Manager, at block 208, which performs 
P its administrative function of checking the SUBSCRIBER’S status and storing the email in ASM 

209, which is die SUBSCRIBER'S Inbox. The user can now collect their email from the ASM 
Inbox (using standard Internet protocols such as POP3 or IMAP4) through the user email client 101 
on their computer. Their «mh 1 j 8 100% spam-free, since all e m ai l from scutes not recognized by 
25 the system as authorized has been rejected. The SMTP Receive Manager 208 is also configured to 
log die j fi formation of receipt of the email from a FRIEND and send it to the ASL 203b for further 
analysis, as indicated at block 210. 

Users send email composed on and sent from the email client 101 via standard 
30 SMTP protocols to the ISPs email server. The ISP's SMTP server is responsible for providing 
users with email addresses within the system, and sending users 1 email to foe recipients 1 email 
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adOieasea on the Internet 103. In the SPAMKAFU invention system, an SMTP Send Manager 212 
is provided to intervene in fee usual send email process. The SMTP Send Manager 212 copies 
header information from all outgoing email and sends the data to the ASL Man age r 211, then sends 
the email on to its inten ded des tination. The ASL Manager 211 performs one of the key functions 
in tiie invention system. It analyzes the header data from sent email and data from other data 
sources 213 m«mtain«t by the ISP email server system, such as email logs and user-supplied lists. 
On the basis of its analysis routines (to be described in further detail below), the ASL Mana ger 211 




d Wp on senders authorized to send email to the SUBSCRIBERS. The SPAMKAPU system also 
includes User Maintenance Modules (UMM) 214 which allows the user to interact with and upload 
user infi rnimtim 1 to SPAMKAPU for Anther cu stomiz at i on of SPAMKAPU’s email operations for 
the user. 



Referring to FIGS. 3A and 3B, a standard SMTP send email process (Prior Art) is 
shown compared to a modified send email process used in the present invention. In the standard 
send mail process, in FIG. 3A, email sent from the user’s email client to the ISPs email server may 
be pre-processed, such as checking for correct syntax, alias expansion, etc., and to identify the list 
of recipient email addresses (could be 1 or more). The server email manager gets each recipient 
address in turn and attempts to establish a connection to the dest in at i on SMTP server and 
verify if the recipient email address is proper. If negotiation is unsuccessful, an error messa^s 
returned to the sending SMTP server. If negotiation is successful, tire sending server sods the 
my ypigH body to the destination server and performs a proper "close connection" operation. In the 
modified send email process of tire invention, in FIG. 3B, tire email sent from tire client is pre- 
processed, receipient(s) are indentified, and connection^) with tire de stin a tio n servers) are 
pffi-rp p t fd as usual. Upon successful negotiation, the SPAMKAPU SMTP Send Manager 212 
copies the successful recipient email addresses) and sends the data to the ASL Manager 2ll. On 
the assumption that the SUBSCRIBER authorizes email to be received from any person the 
SUBSCRIBER has sent email to, the proper email addresses of persons to whom the SUBSCRIBER 
has sent email are added to tire ASL List of persons authorized to send email to the SUBSCRIBER. 
The sent email da ta can be used in further analyses by the ASL Manager, c.g., to upgrade a person’s 
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aut ho rize d status from temp o ra ry to permanent if more than a threshold number of e m ai l is sent by 
the SUBSCRIBER to the same person. 



Referring to FIGS. 4A and 4B, a standard SMTP receive email process (Prior Art) is 
3 shown compared to a modified receive email process used in the present invention: In die standard 
receive email process, in FIG. 4A, email is received by the SMTP server from sender sources on 
the Internet and the server stores the email in the user's Inbox. In the modified receive email process 
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of the invention, in FIG. 4B, the received email is subjected to processing by the Redirector 202 to 
deter mine if the sender's address is that of an authorized parson on the ASL List If authorized, the 
10 SMTP server stores the email in the user's Inbox after the SMTP Receive Manager 208 captures the 
sendei's'Vaddress an die email in the address log step 210 to be sent to the ASL Manager 211. Even 
tAfig fr jtto sender is already on die ASL authorized persons list, the received email data can be used 
in further analyses by the ASL Manager, e.g., to upgrade a persons authorized status from 
temporary to permanent if email from that person is received on an ongoing basis ami has not been 
IS changed by die user. 



In FIG. 5, a process flow diagram illustrates the operation of the Spam Processor 
203. At block 501, a request from the calling routine, here Redirector 202, seeks validation whether 
a received email is from an authroized sender. The request identifies die parameters who the email 
20 is FROM and who it is sent TO. The Spam Processor 203 uses the TO address to lookup that user's 
ASL list 203b in die SPDB Database 203a, as indicated at block 502. The lookup procedure 



follows a loop 503 of reading the next ASL record an the user's ASL list, checking far a m at ch to 
the FROM address (authorized person), reading die next record if there is no match of the 
current record, executing the match condition by issuing a TRUE 'value if found, otherwise 
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returning for die next record, as indicated at block 504. At block 505, if a TRUE VALUE is issued, 

or S9 ^ 

then at block 505 die action is taken of setting the outnut value to FREEND^sthcarwisp rf no THUD' nAy 
oiS spe The. A su Cxfcc'Hbt 9 ik -Writer eleteU bdoujj . 

yol tt o is issu ed aft e r mo catas list totwi uro e e as e d, t h e aatiou is t aken uf suull iy duT uui put l alua . 

u/rft\ anw ArgjqopftfVTg < ccrtutiieo. 

toPPAMMH k At block 506, the returned value is sent as a ^rasa^totoe^calling routine, i.e., the ^ 

Redirector 202. If the re t urn e d vahir is SffAMMBTl, a wtnnd a rrl nrror message is tHC lt MBd . As a r tofto 

default option, if no ASL list is found for the user, the system returns the value FRIEND, as 



indicated at block 507, in order to allow the email to be accepted as a temporary condition until an 
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ASL list can be established for dial user. The request processing routine can be implemented using 
indu str y s tandar d PERL programming syntax and inc o rporating a PERL interpreter to execute the 
processing rules. 

In FIG. 6, a proems flow diagram illustrates the detai l ed operation of foe Web-Based 
Messenger (WBM) routine for handling email rejected by foe Redirector 202 (see FIG. 2). 
Preferably, foe WBM process is implemented via interaction with a rejected sender at a separate 
Web site address. In Phase 1, corresponding to step 204 in FIG. 2, foe WBM process is initialized 
at block 601 by foe ASL rule returning a value for rejecting an email as sent from a SPAMMER by 
foe Redirector 202. At block 602, a unique ID number is a ssigned to th e nwnil in foe WBM 
database and a given expiration date is set, c.g., 48 hours. At block 603, a return me ssage is added 
along with the unique ID code to foe body of the SPAMMER'S email and sent back to foe sender's 
email address in order to notify foe SPAMMER to go to the WBM web page if they wish to follow 
through wife contacting the SUBSCRIBER. The WBM then waits for the SPAMMER to go to foe 
WBM site to complete the process, referred to as Phase 2. At block 604, the SPAMMER accesses 
foe WBM web site and agrees to the displayed terms and conditions of usage. At block 605, the 
WBM process verifies that foe time for response for the email corresponding to the ID number has 
not expired. The WBM then follows a test procedure to ensure that foe responding SPAMMER is 
not b ei ng implemented by a mechanical program. For example, at block 606, a word' stylized in 
non-standard font can be displayed as a graphic image, and at block 607 foe SPAMMER is 
prompted to type the word that appears in the graphic. A mechanical program would not be able to 
read a graphi c image of a word in unrecognizable font. At block 608, if the WBM process 
determines that a correct word has been typed, foe SPAMMER'S status is upgraded to SUSPECT on 
the user's ASL list At block 609, foe WBM process presorts a form to enable the SUSPECT to 
CTrter a short me ss a g e to be sent to the SUBSCRIBER For example, foe SUSPECT can ask the 
SUBSCRIBER to make sure the anti-spam control has been updated to allow email. At block 610, 
the «mail and message is sent, by routing directly to the ASM email box for the SUBSCRIBER, 
along with modification of the header to include a codeword or flag, c.g., adding the word 
"contact: ” to foe subject line. The codeword can be discerned in the ASM email logging step 210 in 
FIG. 2, in order to differentiate the redirected email from other email determined to be authorized 
email. At block 611, the SUBSCRIBER can now read the SUSPECTs email. If the SUBSCRIBER 
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a reply to the email, the SUSPBCTs status may be automatically upgraded to FRIEND, or die 
SUBSCRIBER may upgrade die status to FRIEND manually by interaction with the ISP email 
server through the UMM 214. At block 612, if die SUBSCRIBER determines that the email is from 
s omeo ne whose should be rejected without a WBM error reply option, die SUBSCRIBER 
may optionally downgrade the status permanently to SPAMMER through die UMM 214. 

Referring to FIG. 7A, a block diagram illustrates a standard SMTP send-reedve 
«n«ii handling process (Prior Art), as compared to FIG. 7B which shows a modified Redirector 
pro cess for handling received email. In the standard process, die Sender-SMTP 701 requests 
connection to the Roceivor-SMTP 702, which accepts, the connection if available. The Sender 
SMTP then performs die task in its Scad Email loop of sending die recipient's email address. At 
block 703, the Receiver-SMTP confirms or denies whether the recipient exists or whether it las 
authority to process crodi for this uses. If confirmed, the Sender-SMTP sends die message body 
and marks the end of the message. At block 704, .the Receiver-SMTP receives the message body 
and sends it to die email box of die recipient (or recipients if the message is sent to more dun one 
recipient at that SMTP server address. 

In FIG. 7B, the Sender-SMTP 701 and Receiver-SMTP 702 perform their usual 
establishing of a connection md check for valid receipient e-mail add r es s . However, in this 
modified process implemented in coryunction with die Spam Processor 705, die sender’s FROM 
is stored by the Spam Processor for later use, as indi c at ed at block 706. At block 707, die 
sender's FROM address and the recipient's TO address are sent to the Spam Processor 705, try a 
request for validation by the Redirector as described previously. At blodc 708, after checking the 
recipient’s ASL list to determine whether the sender is authorized, die Spam Processor can return a 
response of FRIEND or a response of SPAMMER with an accompanying emir message. If die 
response is FRIEND, an output is sent to the Sender-SMTP confirming that die email can be 
received, and the email is sent to die Receiver-SMTP as usual. At block 709, the Receiver-SMTP 
puts the email in the recipient's email box and, if desired, can include a message noting that the 
saidcr was identified on the ASL list as a friend. If die response is SPAMMER, then an error 
message is returned to the Sender-SMTP that the recipient does not exist or the Recipient-SMTP is 
not authorized to accept the email. Optionally, the Receiver-SMTP may send the email through the 
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WBM process* as described previously (i n dicated at block 710), if fee response from fee Spam 
Processor feat fee status of fee Bender is an unknown sender (as opposed to having fee 

confirmed status of SPAMMER). 



/i\ in fig. 8, a schematic diagram illustrates fee structure and operation of fee ASL 

k^-Manager, previously described as component 211 wife respect to JIG, 2. The ASL Manager 
preferably is structured to have an ASL On-Demand Processor 801 and an ASL Scheduler 
Processor 802, both of wh^Bh interact wife an ASL Rules Processor 803, which also exchanges data 
wife the Spam Processor Database (SPDB) 203a. Email addresses sent to and received from the 

10 SMTP Send Manager 212 and SMl^Reccive Manager 208 arc processed by the ASL On-Demand 

Processor 801 which executes the appropriate rules in conjunction wife fee ASL Rules Processor 
803. Content from a variety of other sounxs^mcluding compatible fend party plug-ins, can also be 
processed to create, populate, and update fee ASL Lists stored in the SPDB 203a. For example, 
content may be received from a "Drag and Drop Mah^ger" for conveniently hand l ing user address 
13 inputs while working with the email client, user addresahmuts from Web sites while working wife 
an browser, addresses added by the user to a desktop contact manager, such as fee 

Microsoft Outlook ™ Address Book, or other contact lists, andbfeer address inputs generated by 
third party software that can operate wife the user's client programs. 



20 The ASL Scheduler Processor 802 is used to process tasks on a scheduled basis for 

various armiy rig and maintenance functions. This allows a very rich examination of fee 
SUBSCRIBER’S ASL list, mail log, and other data files, to continually refine fee "authorized 
senders" list for accuracy and relevance. Far example, the processor functions can include: an ASL 
Mail Log Analy zer for analyzing fee ASL Mail Log databas e 803a of fee SUBSCRIBER’S received 
23 and sent emails; an Expiration Date Analyzer for setting and enforcing expiration dates for 
senders to be re-authorized; a Low Volume Analyzer for downgrading or e l i min ati n g fee 
authorization status of senders wife whom the SUBSCRIBER communicates very infrequently; a 
High Volume Analyzer for upgrading or permanently marking the authorization status of senders 
with whom the SUBSCRIBER communicates very frequently; a Fuzzy Logic Analyzer for making 
30 qualitative decisions as to FRIEND or SPAMMER status based on a variety of factore; and other 
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Third Party Analyzers for analyzing data generated by third party plug-ins and programs to refine 
the ASL list 



The ASL Rules Processor 803 contains the rules (in an ASL Manage Rules 
5 Database) that determine how to add, update or modify file ASL Lists maintained in the SPDB 
Database 203a. The Rules Processor can have an architecture that readily accepts and interoperates 
with third party databases 803b and applications programs 803c in order to harness the collective 
power of developers in the network communications indsutry to continually improve and extend file 
SPAMKAPU system's feature set The ultimate result of this architecture is to enable the creation 
10 of a very richly detailed ASL database which goes beyond even the total elimination of spam email 
into other or fiiture needs of users for the dynamic and intelligent h a nd l ing of email. 
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hi FIG* 9, a detailed implementation is illustrated of examples of processing of email 
sendAecdve and user contact data into specific forms of actions taken by the ASL Manager. The 
15 basic process flow consists of. Step 901 of looping through each line of an ASL list (called a Table) 
comparing the FROM address captured from an incoming email for a match; Step 902 of 
^rfmnining whatever condition or status flag has been set for the matched entry, then executing the 
condition rule as on the Condition Table, resulting in return of a Return 

Value; and Step 903, based on file Return Value, executing the corresponding action rule as 
20 maintained on the Action Table, and exiting wilh a Final Return Value from this action. To follow 
one example through this process flow. Step 901 finds a FROM match of the sender address 
Step 902 notes the expiration date condition "before 12/1/2003" and executes the 
"before" condition on the Condition Table to return a value of "True" if today's date iskss than the 
iu&cetori expiration date, and Step 903 notes that foe sender status action (if condition is True) is 
25 "friend” and executes the "friend" action on the Action Table to return a Final Return Value of 
FRIEND (no parameters needed) as the validation response of the Spam Processor. 



The specific programming syntax or execution logic of the ASL Manager rules 
processing may be varied in any suitable maimer depending on the developer of the Spam Processor 
30 application. The following examples of some options for ASL Manager actions illustrate a wide 
range of approaches that may be used: 
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MATCHING AN EMAIL ADDRESS OR ADDRESS PATTERN: 

(a) Default: exact match 

(b) A specific email address: john@wimpany.com 

(c) UNIX Standard wildcard matching: 

* jracrosoft.com = anything from “Microsoft.com” 

*microsoft* ■ anything with microsoft in it 
♦jnil = any email from the military 

(d) Matching any known “blackhole list” by using a %BLACKHOLE% symbol, 

USING A (XJNDmONAL AND PARAMETERS TO EXECUTE IF THE MATCH 
IS TRUE 

USING A SECONDARY ACTION AND PARAMETERS TO PERFORM IF THE 
CONDITIONAL IS TRUE. 

USING THE LAST DATE THE SUBSCRIBER SENT EMAIL TO THIS 
ADDRESS 

USING THE LAST DATE THIS ADDRESS SENT EMAIL TO THE 
SUBSCRIBER 

USING DATE THE RECORD WAS CREATED 

EXAMPLES OF CONDITIONALS THAT CAN BE USED: 

(a) Expiration dates: use a given address until 2/12/2004 

(b) Date ranges: use a given address from 4/1/2004 to 5/2/2004 

(c) Specific recurring times: first week of every month but no other time, e.g., 
newBletter @fflayazfae-com acceptable during 1* week of each month. 

(d) A link to external software designed to allow for additional user-defined criteria; 
this allowB for third party applications 

EXAMPLES OF MESSAGES THAT MAY BE INVOKED BY A OVEN 
SECONDARY ACTION 

(a) Standard “error'’ 

(b) Custom with variable substitution in the message body, e.g.: 

%usemame% is substituted with the sender’s email address 
%subid% is the ID code of the subscriber 
%date% is today’s date 

(c) “hello %usemame% you have been identified as spam, go to 
htto^/www.BDarnkapu.com/subscribeT=y»subid%^ and if you’re really human we’ll let 
you in. 

(d) Custom text: “All email addresses from America Onlinc are unconditionally 
rejected’* 

(e) Send a given message in the error response. 

(f) Send a given message as an email. 
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(g) Open a file and email its contents 

(h) Open a file and send its contents as an etior reponse. 

0) Set the sender’s status to SPAMMER, or PRIBND 

(j) Create a unique ID that will expire after a short time period (24-48his). This id 
can be used by the SUSPECT to access the WBM and become a CONTACT. 

(k) Give SMTP default rarer message 

0) link and execute external software deeped to alk>w for additional user-defined 

actions; this allows for third party applications. 



In su mmar y, the prescot invention provides a spam email rejection method which 
analyzes the sender address of incoming email and determines whether it is to be rejected or 
accepted dep ending upon managed lists of authorized senders. This is a significant departure fan 
wrlgring anti-spam processing systems which accept all email and attempts to filter out only those 
fon t have sender addresses recognized as those of known spammers. The invention method does 
not filter out unauthorized email, rather it rejects all email unless authorized. The ASL Manager in 
foe system captures and analyzes sender and recipient usage patterns for outgoing and incoming 
«n»ii in order to refine the "authorized senders" lists. The analysis of this data provides a rich 
foundation for rotes-based decisions as to which sender addresses are considered SPAMMER and 
which are not This data creates an "authorized sender” list of FRIENDS, as opposed to a list of 
known SPAMMERS, thereby ensuring that no unsolicited or uninvited email will ever pass through 
to the SUBSCRIBER'S eamil box. 

It is understood that many other modifications and variations may be devised given 
the above description of the guiding principles of the invention. It is intended that all such 
modifications and variations bo considered as within die spirit and scope of this invention, as 
defined in the following claims. 
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1 . A system for eliminating umuithori icd email sent to a user on 8 network 

comprising: > 

(b) an email client for allowing the u» r to receive email sent on the network 

addressed to a unique email address of the user, 1 

(b) an emai l -receivin g saver connected b tween the network and the email client 
for receiving email addressed to the unique email addresc of the user, said cmail-recciving server 
having an authorized senders list (ASL) module which ma ntains an ASL list of email addresses of 
sendera authorized to send email to foe user, and 

(c) an gnrui rejection module operable i rifo the ASL module for rejecting foe 
receipt of email addressed to foe email address of the user if foe email address of the sender is not 
one that is maintained on foe ASL list for foe user. 

2. A system ac cording to Claim ^ wher sin foe ASL module includes an ASL 
flafnhaaft for storing ASL lists of authorized sender addi esses for respective subscribers of the 
system, a spam processor module for checking the ASL lis s for matches, and an ASL manager for 
creating, maintaining, and updating the ASL lists. 

3. A system according to Claim 2, further comprising a redirector module operable 
with foe ASL module for receiving an email-sending message des i g n a tin g foe sender's FROM 
address and intended recipient's TO address, for 'Sending 
pro cessor module to determine whether foe sender’s FROM 
address maintained on the ASL list corresponding to foe TCI 
Bf ffj i ft n g the email if a match to an authorized sender address is found, and for rejecting foe email 
if no match to an authorized sender address is found on the ASL list 



4. A system according to Claim 3, further l comprising a web-based messaging 
30 (WBM) module to which email rejected by the redirector mt dule is redirected and which sends a 
message to foe address of foe sender of the rejected email no ifying the sender to confirm that the 



t est for validation to foe spam 
matches any authorized sender 
address of foe intended recipient, for 
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sender is s lpgitiinatc sender of email to the intended recipient. 
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5. A system according to Claim 4 l vwberein the WBM module includes a separate 
web site to which the notified sender can log on and confirm that the sender is a legitimate sender of 

nil through an interaction procedure which can cuuy be performed by a h um a n . 

6. A system according to Claim 5, therein the interaction procedure includes a 
display of a graphic image of a word in a non-standard! font, and an input for tho sender to rater in a 
word corresponding to die graphic image of the worf, whereby the system can confirm that die 



interaction procedure is not performed by a mec hani c al 



{program. 



15 



7. A system according to Gaixn 4, 
legitimate sender of email to die intended recipient 
user’s email box with a code dial in di ca t es that the 
confirmed as legitimate by the WBM module. 



wherein once the sender is c onfirm ed as a 
r, the WBM module sends the email to the 
was rejected by the redirector module but 



us r, 
ana il 



8. A system according to Claim 3, 
for capturing FROM and TO addresses of em ail 
data to the ASL manager for later analysis. 



20 



farfccr comprising an email-teceiving manager 
accep ed by the redirector module and sending the 



9. A system according to Gaim 2, further comprising an email-sending manager for 



capturing FROM and TO addresses of email sent fiozj 
ASL manager for later analysis. 



10. A system according to Claim 2, y /herein the ASL manager further includes a 
rules processor for processing predefined address capti re rules for updating the ASL lists using data 
from an email address source selected from the git ip of email address sources consisting of: 
received «n«l; sent email; user inputs to email servi< e functions on the email client; inputs from 
user browsing of web sites; user desktop organizer on I other contact lists; and third party address 
program inputs. 



the fifnail client and sending the data to die 
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11. A system according to Claim 2j wherein the ASL manager further comprises a 
rales processor for processing predefined analysis rales for updating the ASL lists using data from 
an analysis source selected from foe group of analysis sources consisting of: user email log analysis; 
expiration date analysis; low/high email volume analysis; fuzzy logic analysis; and fond party data 

3 analysis. 

12. A system according to Claim 2, ' vhereih the ASL manager maintains the ASL 
lists Hwrf glinting a sender-address status selected from foe group of sender-address statuses 
consisting ofl always authorized as a friend; authorize 1 as a friend over a date range; authorized as a 
friend before an expiration date; always rejected as a spammer, rejected as a spammer matching a 
black list; and rejected as a spammer sent with an erro ■ message. 

13. A method for eliminating unaui lorized email sent to a user on- a network 
comprising foe steps of: 

(a) receiving email addressed to' the unque email address of foe user, 

(b) maintaining an authorized senders 
users authorized to send email to foe user, and 

(c) rejecting the receipt of email sent to foe email address of the user if the email 
address of foe sender is not one maintained on foe ASli list for the user. 



hist (ASL list) of email addresses of external 



14. A method according to Claim 13, father comprising foe step of redirecting foe 
rejected email to a web site for sending a message to t le 'sender of the rejected email notifying the 
sender to confirm that the sender is a legitimate sender < f email to foe intended recipient 



23 15. A method according to Claim 14, farther comprising foe step of performing an 

interaction procedure at the web site with foe notified (sender which can only be performed by a 
human. 



16. A method according to Claim 13,1 wherein said ASL list maintaining step 



30 includes updating the ASL lists using data captured 
email; sent email; user inputs to email service fonctio 



any of foe following sources: received 
i inputs from user browsing of web sites; 
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user desktop organizer and other contact lists; and jhird party address program inputs. 

17. A method according to Chrifcn 13, wherein said ASL list maintaining step 
includes updating the ASL listsusing data obtained from analysis of any of die following factors: 
user email log analysis; expiration date analysis;] low/high email volume analysis; fuzzy logic 
analysis; and third party data analysis. 



18. An email server system for el 
the server addressed to a unique email address for a i 

(a) an authorized senders list (ASL)| 
addresses of senders authorized to send email to the \ 

(b) an email rejection module 
receipt of email addressed to the email address oft 
one that is maintained on the ASL list for the user. 



; unauthorized email sent via a network to 
r of die system comprising: 
dule which maintain* an ASL list of email 
r, and 

Me with the ASL module for rejecting the 
: user if the email address of the sender is not 



19. An email server system accord: ig to Claim 19, wherein die ASL module 
includes an ASL database for storing ASL lists of authorized sender addresses for respective 
subscribers of the system, a spam processor module fi r checki ng the ASL lists for ma tc he s, and an 

r* 

ASL manager for creating, maintaining, and updating t le ASL lists. 

20. An email server system according to Claim 19, further comprising a redirector 
m od ule operable with the ASL module for receiving! an email-sending message designating die 
sender's FROM address and intended recipient's TO address, for sending a request for validation to 
the spam processor module to determine whether the sender's FROM address matches any 
authorized sender address maintained on the ASL list corresponding to the TO address of the 
intended recipient, for accepting die email if a match to m authorized sender address is found, and 
for rejecting the email if no match to an authorized sendet address is found on die ASL list 
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ABSTRACT OP THE DISCLOSURE 

A system for »ii™m«ting unauthorized email sent to a user on a network employs an 
email-receiving server connected between the network and the user's em a il client for receiving 
5 email to the user and rejecting those in which die sender address does not match any of 

iffn jfr addresses maintained on an "authorized senders" list (ASL list). The ASL lists are 
• maintained by an ASL manager in an ASL database operable with a spam processor module. A 
redirector module rejects the email i£ upon sending a request for validation to die spam processor 
modu le, die Bender's address docs not match any authorized sender ad dre ss on the ASL list. Email 
10 rejected by the redirector module is redirected to a web-based messaging (WBM) module which 
a message to the sender to confirm that the sender is a legiti mat e sender of email to the . 
in tended recipient If the sender logs on to confirm their status, the WBM module executes an 
£5 interaction procedure which can only be performed by a human , in order to ensure that the 

g{j confirmation procedure is not performed by a mec h a n ical program. The ASL manager maint a ins 

15 the ASL lists based upon sender address data collected from various sources and analyses of various 

CO email usage factors, including sent email, received email, contact lists maintained by the user, user 

preference inputs, third party programs, etc. 
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